[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5248) non-atomic signal variables



Hallvard B Furuseth wrote:
> hyc@symas.com writes:
>> As I recall, the only reason we needed the waking counter here was to
>> make sure we never filled the pipe buffer, which would cause a
>> single-threaded server to deadlock. We can simply set the pipe to
>> nonblocking instead, and eliminate the counter.
>
> Sounds good...
>
>> The other point was that if there was already a pending wake event,
>> there was no reason to write another one.
>
> Aha!  Now the code makes more sense to me:-)  And if 'waking' is
> just a boolean flag, we can keep it as long as it is treated that way.
>
> #define WAKE_LISTENER(w) do { \
> 	if ((w)&&  !waking) { \
> 		waking = 1; \
> 		tcp_write( SLAP_FD2SOCK(wake_sds[1]), "0", 1 ); \
> 	} \
> } while (0)
>
> I need to stare at it a bit to look for race conditions with readers.
> I don't suggest to hold next RE24 for this though.  It's hardly urgent,
> and should be tested a bit --without-threads first.
>
Actually this can all be simplified even further if you're building 
--without-threads - in that case, the only WAKE_LISTENER call that matters is 
the one made from the signal handler. In every other case, the calling 
function will eventually return and fall back into the main event loop anyway.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/