On Thu, Jun 30, 2011 at 03:05:52PM +0100, Alan Conway wrote: > I'd like to see something like: > > - a thread safe "get next event" call that returns events for > message delivery, async responses and any other triggers coming from > the broker
I definitely like the sound of this. > - a file descriptor that is readable whenever there are qpid events > pending so you can knit this into a poll/epoll/select loop > - an ease-of-use layer that provides ready-made thread pool > implementations of common dispatch policies e.g. message listeners, > thread-per-connection, thread-per-session, thread-per-message etc. > > The ruby integration would use the lower level event handling API to > dispatch qpid events in ruby threads in whatever way is appropriate > and avoid blocking calls entirely. Obviously we're not there yet > but I think we will eventually move in that direction. Given that I'm still fairly new to the team, how far off does that seem on our roadmap? -- 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/
pgpqBrEYF6g1h.pgp
Description: PGP signature
