On Sat, Nov 24, 2007 at 10:57:26PM +0100, Nicolas Favre-Félix <[EMAIL
PROTECTED]> wrote:
> Actually, I get some unpredictable behavior: some of the processes
> receive the callback in which accept() is done, and some don't.
It is quite possible that some of your processes receive the wakeup, one gets
to accept, and the other processes simply never see the event, because they
were busy doing other stuff etc. This depends very much on the backend in use
and your server design, but isn't really a problem as long as _one_ process
gets the connection.
> > kernels (e.g. freebsd and linux) this will only wake up one process, but
> > of course doesn't allow event handling.
> >
> When you refer to bad scalability, are you saying that having lots of
> connections will result in multiple processes trying to accept
> simultaneously, which would impact the performance, all but one failing
> instead of processing client?
Yes, thats exactly what I meant. Depending on your application, this might be
acceptable however, as its also a very simple design.
> If so, would it be better to have 2 threads per server process, one
> blocking on accept() and the other running an event loop?
If your accept rate is very high (like, say, hundreds to thousands of
requests/s), then this sounds certainly better, but you still need an
effective and fats way to then communicate this fd to your worker threads,
preferably from a thread pool for example.
However, since you have a pre-fork model, threads are of no
relevance. Apache actually experimented a lot on how to best accept, but
that always refers to blocking processes - you might use event handling
while serving a request, but not when waiting for an accept.
> I see. Accepting myself is not a problem here.
strongly preferable, in fact .)
> > while (fd == accept)
> > evutil_make_socket_nonblocking (fd);
> > evhttp_get_request(http, fd, sockaddr, addrlen);
> >
> Thanks! This works fine. Actually, I had tried this function after
Oh, thats good, because I only read over the code and intended only to
give you some starting hint, but its even better when it actually works
out of the box.
> > Well, they are "exported", just not "declared", if you will :)
> Should this be declared, then?
Well, I have no say in policy issues (or any issues, really) regarding
libevent (I am only the "libev guy"). I do think the various libevent
APIs are sometimes severely limited, hiding important functionality. For
example, there is no way to make MX lookups using the documented dns
code (because there is no generality at all, just three or so predefined
request functions), although the underlying code clearly can deal with
other resource records.
I find that the libevent API usually exposes what the libevent author(s)
currently needed but nothing else. (This is actually known as the bsd API
style, it isn't necessarily bad!).
> Or will the upcoming libev enable
> fork()-safe event handling once evhttp has been added to it?
libev, unlike libevent, supports forking. it is also not upcoming anymore, as
its fully released.
However, this just means that you can reuse event loops from your parent
process in the child. It does not magically create some IPC channel to
distribute events betweeen processes, and from what I could read in your mail
so far, it looks as if you do not even need this capability, as your style of
forking and only _then_ initialising libevent is *perfectly* safe and
adequate for and with libevent and your program :)
> like to avoid is my code breaking if evhttp_get_request changes or is
> renamed/removed.
Then you need the libevent maintainers make a committment to both expose
this API and keep it in the future.
Who knows, they might just do that, and you are exactly in the right list
to make them hear you :)
> Thank you very much for your help.
Greast that it was actually helpful, after a rough start of misreading your
actual problem :)
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
