> On Sat, Feb 17, 2001 at 08:05:05AM -0800, [EMAIL PROTECTED] wrote:
> > On Fri, 16 Feb 2001, Greg Stein wrote:
> >...
> > > But that is the STM itself. We should be able to code *against* the API
> > > without being subject to the license terms. (the NPL is non-viral)
> > >
> > > It would actually be quite interesting to see APR ported to build
against
> > > STM and see what happens when the threaded MPM is thrown against
APR/STM.
> >
> > Personally, I would go the other direction. Just port the STL to use
> > APR. I just ported the threaded MPm to APR in ten minutes last night (not
> > committed, because I came home and left the computer off), so the port
> > really shouldn't be that hard.
>
> STM is a new user-level threading package. I think you'd want to put it
> under APR.
>
> Porting STM onto APR might be interesting, but I'd be curious as to whether
> you'd be able to get the same semantics (e.g. switching to a different
> thread of execution). It sounds a bit dubious. STM has an API of about 50
> functions, so it might not be a ton of work
With STM, network I/O must never block. The best solution is to go ahead and
make the jump to enable full async network i/o for a kqueue/kevent model.
Bill
