[Libevent-users] fork() causes problems

[Andrew Danforth]

You could call event_init immediately after you fork in a child to get a
fresh libevent instance.  event_init returns a pointer to the event_base for
the new instance which you must store and associate with all future events
you plan to register.  When registering a new event you must first set the
appropriate base with event_base_set.  The last time I looked, the most
recently created event_base is assumed when a specific base is not provided,
but I would not rely on that behavior.

This approach is based upon my understanding of how libevent works
internally, I've never actually used it with epoll on Linux, only devpoll on
Solaris which is similar.  If it works, your children will inherit the
parent's epoll fd but just ignore it.  Not sure if that's the behavior you'd
like.  I'm also a bit curious why you're using libevent in the first place
if the architecture of your app is such that it forks for each client.
libevent, and event based programming in general, allow you to service
multiple clients from the same process quite easily.

Andrew

On 1/22/07, Wilmer van der Gaast <wilmer at gaast.net> wrote:
>
> Hello,
>
> I'm getting very strange behaviour from libevent (when using it with
> epoll()). My program (BitlBee in ForkDaemon mode) has a master process
> which accepts clients and creates a new child process for every
> connection. When using select() or poll() for event handling, this works
> perfectly. However, when using epoll() (which is the whole reason I
> started using libevent, GLib can do event handling with poll()/select()
> already) things go wrong once there's more than one client.
>
> With only one client everything works perfectly, but once there's
> another one, process 1 seems to get the other process' event
> notifications. (Process 2 does get the notifications too, BTW.) Process
> 1 then tries to read from the socket, gets EAGAIN and panics because it
> obviously doesn't expect to get such an error in a "there's data, read
> it" event handler.
>
> Most likely this behaviour comes from the fact that all processes share
> one epoll fd, which is hardly ever a good idea. See this post:
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0403.0/0300.html
>
> So now I'm wondering, how do I make sure every process gets its own
> epfd? I found epoll_base_free(), but it's probably not what I'm looking
> for, because of this line:
>
> assert(TAILQ_EMPTY(&base->eventqueue));
>
> This means that I have to remove all event handlers to make this
> function call successful, right? I really shouldn't do that, because
> most likely doing that will remove the event handler in the parent
> process too!!! (See the rest of the thread above.)
>
> So, does anybody know what to do to make this work properly?
>
>
> Wilmer van der Gaast.
>
> --
> +-------- .''`.     - -- ---+  +        - -- --- ---- ----- ------+
> | wilmer : :'  :  gaast.net |  | OSS Programmer   www.bitlbee.org |
> | lintux `. `~'  debian.org |  | Full-time geek  wilmer.gaast.net |
> +--- -- -  ` ---------------+  +------ ----- ---- --- -- -        +
>
>
>
>
>
> _______________________________________________
> Libevent-users mailing list
> Libevent-users at monkey.org
> http://monkey.org/mailman/listinfo/libevent-users
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://monkeymail.org/archives/libevent-users/attachments/20070122/608fee98/attachment.htm