| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Andrea Grassi" <andreagrassi(at)sogeasoft(dot)com> |
| Cc: | "'Craig Ringer'" <ringerc(at)ringerc(dot)id(dot)au>, harrywr2(at)comcast(dot)net, "'Pg Bugs'" <pgsql-bugs(at)postgresql(dot)org>, "'Alvaro Herrera'" <alvherre(at)commandprompt(dot)com> |
| Subject: | Re: R: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function |
| Date: | 2011-12-21 16:00:34 |
| Message-ID: | 5744.1324483234@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"Andrea Grassi" <andreagrassi(at)sogeasoft(dot)com> writes:
> In internet I searched for detailed specifications of poll/select system
> functions but I didn't understand one thing, that is which one of the 2
> statement is true:
> 1) poll/select wait only for FUTURE modifications of ready-read state of
> sockets
> 2) poll/select check if there is something to read at the moment of the call
> and otherwise wait for FUTURE modifications of ready-read state
#1 is nonsense. If poll worked like that, it would be impossible for
anyone to use it without suffering from race conditions. But if you
don't see where exactly the poll() specification says so, I observe
that it says first that poll sets the bit(s) if the requested condition
is true, and second that *if* none of the events have occurred yet,
poll should wait. See for instance
http://pubs.opengroup.org/onlinepubs/007908799/xsh/poll.html
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2011-12-21 16:25:53 | Re: BUG #6348: PROBLEMAS DELETE |
| Previous Message | Tom Lane | 2011-12-21 15:55:16 | Re: [PATCH v2] Use CC atomic builtins as a fallback |