Hi,
I'm trying to write a simple, fast server for freebsd that can handle
thousands of open connections - all sockets. Tentatively one loop per
thread / one thread per core (not sure how/if I'll get thread affinity).
Anyway, I read a number of concerns about libev & kqueue. Since all I
care
Hi, me again! :)
Marc Lehmann, el 14 de diciembre a las 20:10 me escribiste:
> The bigger problem you will face is that there are ten or so watcher types
> as opposed to only one.
I think I underestimated this issue =P
Is not that is a lot of work typing (that, as painful as it is, it's done
onl
On Wed, Jan 09, 2008 at 01:20:35AM -0800, Eric Brown <[EMAIL PROTECTED]> wrote:
> Anyway, I read a number of concerns about libev & kqueue.
What concerns? libev supports kqueue just fine... It is kqueue that is making
problems on most BSDs, though.
> Since all I care about are sockets, can I get
On Jan 9, 2008 8:28 AM, Leandro Lucarella <[EMAIL PROTECTED]> wrote:
> Is not that is a lot of work typing (that, as painful as it is, it's done
> only once ;), but the lack of a base "class" to have a container of
> watchers.
>
> I thought about a lot of solutions, but all has their drawbacks:
>
Hi Marc,
On Jan 9, 2008, at 7:58 AM, Marc Lehmann wrote:
> On Wed, Jan 09, 2008 at 01:20:35AM -0800, Eric Brown <[EMAIL PROTECTED]
> > wrote:
>> Anyway, I read a number of concerns about libev & kqueue.
>
> What concerns? libev supports kqueue just fine... It is kqueue that
> is making
> probl
Shouldn't the #include in ev++.h be #include "ev.h" instead?
If not, what am I missing?
Thanks,
Matt
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
On Wed, Jan 09, 2008 at 10:20:13AM -0800, Eric Brown <[EMAIL PROTECTED]> wrote:
> wasn't always clear to me as to whether the concerns were about kqueue
> or about the way libev uses kqueue. Hence my question. :)
>
> Assuming I go with libev (likely), I'm developing on leopard but my
> target
On Wed, Jan 09, 2008 at 05:35:52PM -0700, Matt Tolton <[EMAIL PROTECTED]> wrote:
> Shouldn't the #include in ev++.h be #include "ev.h" instead?
> If not, what am I missing?
Depending on the problem, you might indeed want "ev.h" there. You can
actually override how exactly ev.h is being included b
So, let's say we have an application that monitors signals through libev,
great!
But, rather than using ev_child, we have our own (legacy) SIGCHLD handler
which does all sorts of fantastic legacy stuff and doesn't exactly map onto
ev_child very well...
It'd be super handy if there were a way to u
On Wed, Jan 09, 2008 at 08:36:32PM -0700, Tony Arcieri <[EMAIL PROTECTED]>
wrote:
> But, rather than using ev_child, we have our own (legacy) SIGCHLD handler
> which does all sorts of fantastic legacy stuff and doesn't exactly map onto
> ev_child very well...
Or maybe it maps fine, but you can't
> Depending on the problem, you might indeed want "ev.h" there. You can
> actually override how exactly ev.h is being included by providing the EV_H
> macro.
I do this, but it seems to me that for consistency it should be "ev.h"
in ev++.h as it is in event.h.
_
On Wed, Jan 09, 2008 at 10:01:17PM -0700, Matt Tolton <[EMAIL PROTECTED]> wrote:
> > Depending on the problem, you might indeed want "ev.h" there. You can
> > actually override how exactly ev.h is being included by providing the EV_H
> > macro.
>
> I do this, but it seems to me that for consistenc
12 matches
Mail list logo
