Hi Alan, I'm pretty sure that libtask does not have this limitation; it is possible to run a libtask event loop in several native threads, and if not, it would be a fairly trivial change, so long as each task could only be scheduled within a single thread.
Mongrel2 is not architected to allow this though, as there are no locks around any of the shared data. Mongrel2 is specifically single-threaded (except for zeromq, which is multi-threaded under the hood) so that it doesn't suffer from many subtle bugs that can happen in multithreaded applications. -Jason On 13:59 Wed 27 Mar , alan turing wrote: > It's theoretical exploration, and I agree with you that the bottleneck > will be the application, but still because the mongrel2 abstractly is > like any internet network server, my points true also in practice ;D > I just want to know the mind set of the architecture and why this is > was the approach.. > and if do you familiar other network server that already used libtask. > Thanks@ > > On Wed, Mar 27, 2013 at 1:04 PM, Jonas Pfenniger (zimbatm) > <[1][email protected]> wrote: > > @alan: are you having actual performance issues or is it more of a > theoretical exploration ? > In practice it's more likely that the bottleneck will be your app IMO. > > On 27 March 2013 09:17, alan turing <[2][email protected]> wrote: > > This is not break the paradigm, you can have libtask handling per > native thread (core) in one process, and earn resilient > architecture: *shared data structures > > *don't need route incoming connection to mongrel2 process > > *SSL session cache > > *eliminate file system locks accessed from multiple processes > > *smart connection pooling to 0MQ > > *more operations friendly design (e.g statistics can be collected from > one process) > > You decide this approach because libtask "feature", or I am missing > something...? > On Wednesday, March 27, 2013, Josh Simmons wrote: > > On Wed, Mar 27, 2013 at 7:02 AM, alan turing <[email protected]> > wrote: > > And what about shared data structures - you will start with shared > memory and such solutions, it could be very complex for a lot of > perspectives... > > did you investigate why libtask has this limitation?? > > Thanks! > > Cheers. > > This limitation is actually a feature of the design. > [3]http://en.wikipedia.org/wiki/Coroutine > > References > > 1. mailto:[email protected] > 2. mailto:[email protected] > 3. http://en.wikipedia.org/wiki/Coroutine
