Thanks for your responses. I uploaded as GIST my PoC code, if anyone would like to see the code or send any improvement:
https://gist.github.com/cr0hn/e88dfb1fe8ed0fbddf49185f419db4d8 Regards, El miércoles, 20 de abril de 2016, 1:00:08 (UTC+2), Imran Geriskovan escribió: > > > 1. With threads you need more locks, and the more locks you have: a) > the > > lower the performance, and b) the greater the risk of introducing > > deadlocks; > > So please keep in mind that things are not as black and white as "which > is > > faster". There are other things to consider. > > While handling mutually exclusive muItithreaded I/O, > you dont need any lock. Aside from generalist advices, > reasons for thinking to go back to threads are: > > 1) Awaits are viral. Async programmining is kind of all_or_nothing. > You need all I/O libraries to be async. > > 2) You cant use any blocking call anywhere in async server. > If you do, ALL your server is dead in the water till the return > of this blocking call. Do you think that my design is faulty? > Then look at the SSH/TLS implementation of asyncio itself. > During handshake, you are at the mercy of openssh library. > Thus, it is impossible to build medium to highload TLS server. > To do that safely and appropiately you need asyncio > implemenation of openssh! > > 3) I appreciate the core idea of asyncio. However, it is not cheap. > It hardly justifies the whole new thing, while you can only > drop "await" s and run it as multithreaded and preserving compatibility > with all old libraries. If you did not bought the inverted > async patterns, even you still preserve your chances of migrating > to any other classical language. > > 4) Major Down side of thread approach is memory consumption. > That is 8MB per thread on linux. Other than this OS threads are cheap > on linux. (Windows is another story.) If your use case can afford > it, why not use it. > > Returning to the original subject of this message thread; > as [email protected] <javascript:> proposed certain combinations of > processes, > threads and coroutines definetely make sense.. > > Regards, > Quick Reply >
