* 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
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
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.
* 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
* 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
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
* 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);
>
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
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
* 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
10 matches
Mail list logo