Re: Events

[Tommi Virtanen]

On Tue, Jun 27, 2000 at 01:29:30PM +0300, Christoph Rohland wrote:
> > > For example we have a thread, this thread handle the file
> > > IO. When I'm wating for some data I can use the select
> > > function to check it out if there is anything for me. If I
> > > want to stop the thread during the select, I have no other
> > > way except for the signal handlers functions.
> > > It is not really handy, because the example above is too
> > > simple. In our case is much more difficulter.
> > 
> > Signal handling should do the job fine.
> 
> No, that's not right (and would be _really_ happy to stand
> corrected). select and signals for interruption are not
> compatible. You always have a race condition between unblocking the
> signal and actually getting into select. AFAIK POSIX defines the
> pselect call for this problem which also introduces a signal mask
> argument. Without this, signals are useless to interrupt select.

	That sounds like you might want to use this trick
	from http://cr.yp.to/docs/selfpipe.html:

--8<--
   Conventional wisdom says that you can't safely mix select() with
   SIGCHLD (or other signals): the SIGCHLD might go off while select()
   is starting, too early to interrupt it, too late to change its
   timeout.

   Solution: the self-pipe trick. Maintain a pipe and select for
   readability on the pipe input. Inside the SIGCHLD handler, write a
   byte (non-blocking, just in case) to the pipe output. Done.

   Of course, the Right Thing would be to have fork() return a file
   descriptor, not a process ID.
--8<--

-- 
tv@{{hq.yok.utu,havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
unix, linux, debian, networks, security, | Three things are certain:
kernel, TCP/IP, C, perl, free software,  | Death, taxes, and lost data.
mail, www, sw devel, unix admin, hacks.  | Guess which has occurred.