On Tue, Aug 15, 2000 at 05:09:34PM -0500, Steven Hazel wrote: > Brandon <blanu at uts.cc.utexas.edu> writes: > > > The API should block on request. That's why we have threading. I certainly > > don't want to have to do a request and then keep checking to see if the > > request has come in yet. > > > > I don't see why you'd want to make requests non-blocking. I'm using the > > blocking request right now and have a perfectly nice NNTP gateway server > > which never waits for requests. It updates its cache of messages in the > > background through the beauty of launching a new thread for each request. > > I agree with Brandon. Non-blocking IO is for environments where > threading is either not available or comes with a significant > performance hit. Both Python and Java show a clear preference for > blocking IO in their base libraries, for example. It might be nice to > provide a non-blocking function as well, but blocking IO should > definitely be the first priority.
I fully agree with both Brandon and Steven. Everything that can be done with non-blocking IO can be done with multithreading (which is often much easier, provided you make your code reentrant and thread safe (which is a good idea, even if you aren't using multithreading at the moment - it will make adding multithreading later much easier)). You could still have a non-blocking interface, but you should also have a blocking interface which is just as functional as the non-blocking interface. For most things you do not need non-blocking (which is a pain to use when you don't need it). -- Travis Bemann Sendmail is still screwed up on my box. My email address is really bemann at execpc.com. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 1625 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000815/5cb2fd6b/attachment.pgp>
