Re: libeio EIO_STACKSIZE

2013-01-24 Thread Konstantin Osipov
* Marc Lehmann [13/01/24 11:18]: > On Wed, Jan 23, 2013 at 06:11:20PM +0400, Konstantin Osipov > wrote: > > * Marc Lehmann [13/01/23 17:50]: > > > Note also that the solution to having your own threadpool is simply... > > > having your own threadpool. > > > > Forking libeio is and (has always

Re: libeio EIO_STACKSIZE

2013-01-24 Thread Gabriel Kerneis
On Thu, Jan 24, 2013 at 02:17:49PM +0400, Konstantin Osipov wrote: > There is a win for us since there is no other library out there > which can do async getaddrinfo() and integrate well into libev > event loop. You might want to consider Chroboczeck's threadpool, designed exactly for this purpose

Re: libeio EIO_STACKSIZE

2013-01-24 Thread Marc Lehmann
On Thu, Jan 24, 2013 at 02:17:49PM +0400, Konstantin Osipov wrote: > > > Forking libeio is and (has always been with free software) > > > an obvious option. > > For these we need a reliable thread-pool of "gophers", i.e. > performers of random tasks, and libeio eio_custom fits here pretty > well.

Re: libeio: discrepancy between the manual and the code

2013-01-24 Thread Konstantin Osipov
* Marc Lehmann [13/01/24 11:18]: > > In my view, it's important to make sure the callback is always, > > otherwise it's hard to reliably manage resources associated > > with eio function arguments. > > I am not sure I can follow. I certainly never felt it as very hard to > manage resources - c

Re: libeio EIO_STACKSIZE

2013-01-24 Thread Konstantin Osipov
* Marc Lehmann [13/01/24 11:18]: > While this is completely unrelated, this is wrong on so many levels: > > 1. 64 bit pointers don't give you millions of stacks, they are a >requirement, but not sufficient. For example, on very common >amd64 hardware your address space is enough for ~16

Re: libeio: discrepancy between the manual and the code

2013-01-24 Thread Jonathan Neuschäfer
On Thu, Jan 24, 2013 at 02:37:27PM +0400, Konstantin Osipov wrote: > ssize_t > coeio_custom(ssize_t (*func)(va_list ap), ev_tstamp timeout, ...) > { > struct coeio_task task; > task.fiber = fiber; > task.func = func; > task.result = -1; > va_start(task.ap, ti

Re: libeio: discrepancy between the manual and the code

2013-01-24 Thread Konstantin Osipov
* Jonathan Neuschäfer [13/01/24 22:00]: > > ssize_t > > coeio_custom(ssize_t (*func)(va_list ap), ev_tstamp timeout, ...) > > { > > struct coeio_task task; > > task.fiber = fiber; > > task.func = func; > > task.result = -1; > > va_start(task.ap, timeout); >

Re: libeio: discrepancy between the manual and the code

2013-01-24 Thread Marc Lehmann
On Thu, Jan 24, 2013 at 02:37:27PM +0400, Konstantin Osipov wrote: > If thread 1 decides to cancel the task, it needs a way to find > out that thread 2 is no longer using struct task *, so that it can > be freed. Thread programming is full of synchronisation problems, and this should be easy to

Re: libeio EIO_STACKSIZE

2013-01-24 Thread Marc Lehmann
On Thu, Jan 24, 2013 at 05:18:37PM +0400, Konstantin Osipov wrote: > At the same time I have yet to see a reasonable > application that is using more than a hundred of thousands of I agree, but we disagree on requiring 64 bit operating systems or wasting hundreds of MB of virtual memory for libe

Re: libeio: discrepancy between the manual and the code

2013-01-24 Thread Konstantin Osipov
* Marc Lehmann [13/01/24 22:16]: Marc, I'm sorry, but I find this your last e-mail rather beside the point. I merely pointed out a discrepancy between the code and the manual, and, upon your request, explained why I think the manual needs to be fixed, rather that the code. Thanks. -- http://ta