Subj : Re: pthreads: combine condvar and select
To   : comp.programming.threads
From : Bernhard Roessmann
Date : Wed Jan 12 2005 11:50 pm

Hi Sean,

>>or some other sort of unix "standard IPC" mechanism, I know.
>>But this seems to be much overhead for sending a little "event" to the thread.
> 
> Compared to the cost of blocking in select and later waking from it 
> and reading from the fd, the cost to write to a pipe or unix socket
> is going to be incremental. It doesn't make sense to worry about it,
> especially since there is no better alternative.
> 
>>I'm amazed why pthreads "signaling" is not "select compatible", this would be 
>>very nice an consistent.
> 
> Yes, and also POSIX and SysV message queues, and async io completions, etc...
> Solaris 10 has a solution for this, which might eventually be standardized.
> 
>>Anyway, seems that I have to use some of the heavier IPC mechanisms for this :-/
> 
> And, other threads in this group have shown that a pipe can be surprisingly 
> performant, compared to the other supposedly "light-weight" mechanisms. 

Hmmm, I think I should write some IPC comparison programms for myself...

 >
>>BTW: UDP is per definition "unreliable". But I think, UDP over a unix socket 
>>should be reliable, right?
> 
> You could also use a pipe.  For inter-thread communication, you can just write 
> pointers into it, rather than entire data structures. And you can set the
> (non)blocking mode at each end of the pipe separately, since you probably want
> the writer to block on a full pipe, while the read end should be nonblocking.

Ok, many thanks for your animations..

Regards,

-- 
Bernhard Roessmann
Don't Fear The Penguins!

.