Re: Forked calls

2010-10-25 Thread Peter Kümmel
> > - compiler update > > - boost update to 1.44 There's a typo in the log message (1.43), but it IS boost 1.44. Peter

Re: Forked calls

2010-10-25 Thread Peter Kümmel
Am Montag, den 25.10.2010, 20:30 +0200 schrieb Peter Kümmel: > Am Montag, den 25.10.2010, 14:33 +0200 schrieb Pavel Sanda: > > Most probably Peter, > > > > is there some way how to get rid of this: > > maybe > - compiler update > - boost update to 1.44 I've updated boost. (Updating boost was ne

Re: Forked calls

2010-10-25 Thread Peter Kümmel
Am Montag, den 25.10.2010, 14:33 +0200 schrieb Pavel Sanda: > Most probably Peter, > > is there some way how to get rid of this: maybe - compiler update - boost update to 1.44 - using Qt signals - suppressing the warning -Wno-ignored-qualifiers > CXXForkedCalls.o > /usr/lib/gcc/i686-pc

Re: forked calls

2002-10-31 Thread Angus Leeming
On Thursday 31 October 2002 12:25 pm, Lars Gullik Bjønnes wrote: > | I see that nobody has commented on my zombies patch. > | Shall I just apply it? > > why not... Ok. But before I do, I think that the current code leaks. I've got this right too, haven't I? (See below). Angus // generate child

Re: forked calls

2002-10-31 Thread Lars Gullik Bjønnes
Angus Leeming <[EMAIL PROTECTED]> writes: | If execvp fails, shouldn't we ensure that the child returns an | appropriate exit value? Wouldn't this also fix the crash we currently | experience if execvp fails? > | #ifndef __EMX__ | pid_t cpid = ::fork(); | if (cpid == 0) { // child |