Marc Lehmann wrote: > I hope you also initialise libevent only in the child, too (or indeed use > fork or select), as kqueue etc. will not work in the child processes. > I do, yes. > The only problem I see with your approach is that it scales badly, as all > processes got woken up that way and then fight for the new connection. But > thats not really a problem unless you want high performance, and is a correct > approach, which is most important. > Actually, I get some unpredictable behavior: some of the processes receive the callback in which accept() is done, and some don't. It seems that the first process to succeed in making the accept() call somehow marks the connection as accepted, which prevents other processes from being warned - you know how it works better than I do. If I add a sleep(1 sec) before accept() I see all the children processes going into the callback - for one of them only to get other than -1 on accept().
> If you can block when idling (as opposed to having to handle events) you > could also just call accept() in each child - on the more prestigious > 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? If so, would it be better to have 2 threads per server process, one blocking on accept() and the other running an event loop? > It is also not sure wether this is what you want, you want to handle a > request on a socket you already accepted (unless you want evhttp to do its > accepting). If you are logging, libevent will also flood you with false > warning messages because it doesn't expect accept not returning a new > connection). > I see. Accepting myself is not a problem here. > 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 looking at http.c, but made a stupid mistake... I wasn't using the right file descriptor :) I'm glad you backed up the same solution. > This is of course not prototyped in evhttp.h and undocumented, but it > seems quite fashionable to work around the limitations of the public > libevent API by calling those private (but non-static) functions. YMMV This will do for the moment. >> I checked http.c but couldn't find any exported function doing this. If this >> isn't implemented, would it be OK to submit a patch to add this feature? >> > Well, they are "exported", just not "declared", if you will :) > Should this be declared, then? Or will the upcoming libev enable fork()-safe event handling once evhttp has been added to it? What I'd like to avoid is my code breaking if evhttp_get_request changes or is renamed/removed. Thank you very much for your help. Nicolas _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
