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) < [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 <[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. >>> >>> http://en.wikipedia.org/wiki/Coroutine >>> >> >
