Quote:
Originally posted by Perderabo
I didn't really follow all of that, but I would try to go in one of two directions...
1) Lose that memory queue
--snip--
2) Lose that pipe
--snip--
1) Well, the memory queue is a requirement because the pipe has a byte limit and given the threaded nature and the need for mutex protection it is possible that I run up against a deadlock because the read thread is trying to lock a structure to handle a request and the write thread has it locked but can put it on the pipe because of the byte limit.
I found that out the hard way...and that's why the single byte on and off to prevent this.
2) That's so close to polling it might as well be polling and would decrease the overall responsiveness of the system because I'd have to wait for socket events, switch to wait for response events, and then back. This also wastes CPU cycles as most polling type activity does...and that's bad practice IMO.
As for the race condition...there really is not worry there. First the mutex will protect the memory queue. So a thread putting a request on it has a consistent view of whether it is the first to put a request on or not. The thread taking the data off then (after it locks the mutex) has a consistent view of whether that item is the "last" item. If another is to be added the mutex has to be aquired, which it can not be until the read thread either removes the byte and the request (or the write thread places the byte and the "first" request).
What I'm really looking for is a way to, maybe with fcntl, make a file (rather than a pipe...maybe one open to /dev/null) readable and then non-readable so that a select can see the readable flag set, and then I can clear it. This is acheived with the single byte outstanding on the pipe...but I'm looking for a cleaner way.
Thanks for the suggestions, if you have any more ideas I'd love to hear them.