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/
pgpOtJdZj08Od.pgp
Description: PGP signature
