Skip site navigation (1) Skip section navigation (2)

Re: R: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function

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: (view raw, whole thread or download thread mbox)
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

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Alvaro HerreraDate: 2011-12-21 16:25:53
Subject: Re: BUG #6348: PROBLEMAS DELETE
Previous:From: Tom LaneDate: 2011-12-21 15:55:16
Subject: Re: [PATCH v2] Use CC atomic builtins as a fallback

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group