Greg / Phlip Yerp, for my current problems green threads are not a good solution, beanstalkd / backgroundrb etc are all good solutions. I think Im going to code a simple messaging system from scratch though so I can keep it simple and more importantly ensure it has a chance of working on windows and that it is self spawning. When I looked at messaging systems a few months ago they required cygwin to run under windows.
IMHO, "Threads are like goto" is a little harsh ... But the more I think about it a well implemented actors model http://en.wikipedia.org/wiki/Actor_model seems way more attractive than threads. Go Rubinius :) Sam On Tue, May 27, 2008 at 9:09 PM, Phlip <[EMAIL PROTECTED]> wrote: > Greg Borenstein wrote: > > I may be totally off base here as much of the technical discussion >> involving details of how gui toolkits normally handle this stuff is over my >> head, but could you maybe handle your situation by using queues to tie >> things together? For example, beanstalkd is a solid, scalable queuing >> implementation with a good ruby front end: >> >> http://xph.us/software/beanstalkd/ >> >> If you had one queue between each pair of processes (log parsing <-> sql >> lite, sql lite <-> shoes) your consumer could just pull of the new messages >> from the queue at its own rate without having to block waiting on the other >> process to answer a query and without having to deal with the complexity of >> spawning additional threads. >> >> Is this on the right track at all? >> > > Absolutely. > > Threads are like goto. >
