Re: [RFC] extending ev++.h to add C++ loop wrappers.

2008-01-15 Thread Marc Lehmann
On Tue, Jan 15, 2008 at 11:34:41AM -0200, Leandro Lucarella <[EMAIL PROTECTED]> wrote: > > Hmm, the loops are not polymorphic, so the dynamic_cast will not be helpful. > > In any case, is_default == (loop_ == ev_default_loop (0)). > > They are in the patch I sent =) > Just for the fork() and dest

Re: Disabling the SIGCHLD handler

2008-01-15 Thread Marc Lehmann
On Tue, Jan 15, 2008 at 08:28:34PM -0700, Tony Arcieri <[EMAIL PROTECTED]> wrote: > Marc, could you check out the Rubinius code? I know when you looked at Rev > you spotted some obvious problems right away. If there's a problem with the > way Rubinius is doing SIGCHLD maybe you could correct it

Re: Disabling the SIGCHLD handler

2008-01-15 Thread Marc Lehmann
On Tue, Jan 15, 2008 at 10:47:33AM -0500, Chris Shoemaker <[EMAIL PROTECTED]> wrote: > It's O(N) in the number of child watchers, and runs only upon SIGCHLD. Also, it just occured to me that this is totally misleading: Your algorithm is O(c²) where c is the number of children in the number of wa

Re: Disabling the SIGCHLD handler

2008-01-15 Thread Tony Arcieri
On Jan 15, 2008 8:17 PM, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Tue, Jan 15, 2008 at 10:47:33AM -0500, Chris Shoemaker < > [EMAIL PROTECTED]> wrote: > > > handler before creating the process, or before the process exits, only > > > before you poll for more events. > > > > I'm glad we finally

Re: [PATCH] Only compile ev::now() if EV_MULTIPLICITY is defined.

2008-01-15 Thread Marc Lehmann
On Tue, Jan 15, 2008 at 10:06:32AM -0200, Leandro Lucarella <[EMAIL PROTECTED]> wrote: > Marc Lehmann, el 15 de enero a las 04:13 me escribiste: > > On Mon, Jan 14, 2008 at 01:35:22PM -0200, Leandro Lucarella <[EMAIL > > PROTECTED]> wrote: > > > Since ev_now() not available if EV_MULTIPLICITY is

Re: Disabling the SIGCHLD handler

2008-01-15 Thread Marc Lehmann
On Tue, Jan 15, 2008 at 10:47:33AM -0500, Chris Shoemaker <[EMAIL PROTECTED]> wrote: > > handler before creating the process, or before the process exits, only > > before you poll for more events. > > I'm glad we finally agree, in practice at least. No, we don't. Your claim was wrong and is wron

Re: Bug with signal delivery after fork.

2008-01-15 Thread Marc Lehmann
On Tue, Jan 15, 2008 at 12:54:59PM -0500, Chris Shoemaker <[EMAIL PROTECTED]> wrote: > I've narrowed this down considerably by tracing both good and bad > executions and comparing. I'll comment the differences in the code: Your test program is still buggy: > ev_default_fork(); > ev_loop

Re: Bug with signal delivery after fork.

2008-01-15 Thread Chris Shoemaker
On Tue, Jan 15, 2008 at 10:50:34AM -0500, Chris Shoemaker wrote: > On Tue, Jan 15, 2008 at 05:06:27AM +0100, Marc Lehmann wrote: > > On Mon, Jan 14, 2008 at 10:56:54AM -0500, Chris Shoemaker <[EMAIL > > PROTECTED]> wrote: > > > I believe the attached program demonstrates some bug related to si

Re: Bug with signal delivery after fork.

2008-01-15 Thread Chris Shoemaker
On Tue, Jan 15, 2008 at 05:06:27AM +0100, Marc Lehmann wrote: > On Mon, Jan 14, 2008 at 10:56:54AM -0500, Chris Shoemaker <[EMAIL PROTECTED]> > wrote: > > I believe the attached program demonstrates some bug related to signal > > delivery after a fork. > > Oh, what you see is that ev_default_

Re: Disabling the SIGCHLD handler

2008-01-15 Thread Chris Shoemaker
On Tue, Jan 15, 2008 at 04:38:54AM +0100, Marc Lehmann wrote: > On Mon, Jan 14, 2008 at 10:38:51AM -0500, Chris Shoemaker <[EMAIL PROTECTED]> > wrote: > > On Mon, Jan 14, 2008 at 03:06:41AM +0100, Marc Lehmann wrote: > > Notice that nothing prevents the waitpid from reaping any child at all. > >

Re: [RFC] extending ev++.h to add C++ loop wrappers.

2008-01-15 Thread Leandro Lucarella
Marc Lehmann, el 15 de enero a las 08:06 me escribiste: > > your opinion before deciding what to do with them, and of course, I want > > to know if there is any interest in merging this to the official libev > > distribution =) > > Yes, there is. Two things are required for inclusion: > > a) it s

Re: [PATCH] Only compile ev::now() if EV_MULTIPLICITY is defined.

2008-01-15 Thread Leandro Lucarella
Marc Lehmann, el 15 de enero a las 04:13 me escribiste: > On Mon, Jan 14, 2008 at 01:35:22PM -0200, Leandro Lucarella <[EMAIL > PROTECTED]> wrote: > > Since ev_now() not available if EV_MULTIPLICITY is not defined, it has not > > much sense having a ev::now() that calls an inexistent ev_now() ;) >