On Wed, Jun 29, 2011 at 04:58:36PM +0100, Gordon Sim wrote: > >1. Create a C++ child class of Session (and other classes that have > >blocking I/O) and, when a blocking call is made, wrap the call in a > >native thread. Then have the native code invoke the lamda funtion, and > >make that lamda a requirement for such a call. > > I'm not too keen on this, it seems at best a short term fix...
I agree. I put that out that as one possible path, but it's too easily a vector for Ruby-specific problems. > >2. Inform the developer that blocking calls will stop the application > >until Ruby 1.9. > > > >Thoughts? > > ...another approach is to ensure that the API being SWIGed supports > non-blocking usage effectively. Though that will take more effort it > seems a nicer solution long term. > > I would certainly like to enhance the c++ messaging API in this way. What do you mean by "supports non-blocking usage more effectively"? What I would like to do, and what is more Ruby-ish, would be to call the non-blocking version but provide a lambda function that can be called. A more Ruby-like way would be to have Ruby _not_ pass :block => true to the underlying implementation and, instead, require the user pass in a lambda function. Then the API could spawn a Ruby thread, do the sync, and then call the lambda function after it completes. So we never _actually_ block the thread while the call runs. But we give the user a means for knowing when the call finishes (which is what I assume is the goal of the synchronous call since it returns no value). How does that sound? -- 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/
pgpQxviYvFIcy.pgp
Description: PGP signature
