What kind of fd is this? Linux? The symptom sounds like what would happen if a TCP socket write were done and TCP buffered the byte. Setting no-delay on the socket would resolve that.
-Steve > -----Original Message----- > From: Darryl L. Pierce [mailto:[email protected]] > Sent: Monday, May 07, 2012 5:17 PM > To: [email protected] > Subject: Strange situation with qpid::sys::Thread and fds > > In reworking the Ruby 1.8 non-block I/O model, I'm banging my head against > a nasty blocker. > > In the new model I have two main types: a Runner and a SynchioCommand. > All of the existing code that was written has been refactored so that each of > the commands (Receiver::Get/Fetch, Sender::Send, etc) are inherit of > SynchioCommand. > > The Runner class implements qpid::sys::Runnable and has a queue that > contains instances of SynchioCommand. > > When a command is created and the start() method invoked, it adds itself to > the Runner's queue. Runner periodically checks the queue and when it sees > a new command, it pops it off the front of the queue, tells it to create the file > descriptor that it uses to communicate with the ruby extension. > > All of this works fine. I've debugged and verified that the fd is created and > properly returned to the Ruby extension, and that the SynchioCommand > runs. The problem is that, after the command finishes running and it pushes > a byte into the fd (changing it's status to readable), the Ruby extension never > sees this. So the blocking I/O command finishes, but then Ruby never wakes > up. > > Any ideas on what would be causing the fd's readable state to not change? > I've tried several different ways to find the problem and nothing has > uncovered the problem... > > -- > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
