<DIV>The 040518 release of CompStrm supports the movement of computational streams to a server thread and back to the main thread.</DIV>
<DIV>See <A href="http://compstrm.sourceforge.net/thread.html">http://compstrm.sourceforge.net/thread.html</A></DIV>
<DIV> </DIV>
<DIV>Thread migration makes it very easy to do blocking I/O without comprimising the main thread.</DIV>
<DIV> </DIV>
<DIV>Unfortunatly, this is still not good enough when working with bsddb, as cursors are NOT thread free. To reuse a cursor, you must be on the SAME thread it was created on. ;-(</DIV>
<DIV> </DIV>
<DIV>A moderatly reasonable solution seems to be to have a thread dedicated to bsddb. Now the business logic can migrate to that thread, do a bunch of blocking I/O, and then migrate back to the main thread. It would then have the option of returning to the bsddb thread and resume processing with cursors it previously created.</DIV>
<DIV> </DIV>
<DIV>Mmm. Looks like its time for me to "put to practice" more of what I've read about Twisted. I'm thinking that managing the bsddb thread might be a Twisted Service--lots better than having each business object instance create its own thread.</DIV>
<DIV> </DIV><BR><BR>Bill la Forge<br>http://www.geocities.com/laforge49/<p><font face=arial size=-1>
<a href="http://in.rd.yahoo.com/specials/mailtg/*http://yahoo.shaadi.com/india-matrimony/" target="_blank">
<b>Yahoo! India Matrimony</a>:</b> Find your partner
<a href="http://in.rd.yahoo.com/specials/mailtg2/*http://yahoo.shaadi.com/india-matrimony/community.php" target="_blank">online</a>.</font>