On Tue, Mar 23, 2004 at 08:53:55AM +0000, Angus Leeming wrote:
> I don't think you've read my proposed code. I'm pretty sure it's
Maybe I just misread it (and now it's deleted).
> > We drop out of the Qt loop to check the sigatomic_t.
> > If it's set, then we go and reap the child, secure that we're
> > not somewhere in the forked controller code.
>
> That was proposal 2 on which you commented: "Excuse me if I'm
> misunderstanding, is this going to busy loop when we've
> no events on the queue ?"
I don't think so. There's a difference between busy looping and a
periodic timer.
> Your just repeating the code I wrote (Proposal 2). Whilst it is good
> of you to comment on my suggestions, I think you might first read the
> code. Saves all sorts of confusion and frustration.
That bit was similar.
> Incidentally, assignments to integer types the size of int or smaller,
> or to pointers, are atomic. So it's perfectly OK to use bool here.
Well if we're being picky, I'm fairly sure that this is not guaranteed
by the C runtime, it just happens to be true on common architectures.
> >> void child_handler(int)
> >> {
> >> while (process_signal) {
> >> process_signal = false;
> >> ForkedcallController::get().handleCompletedProcesses();
> >
> > Racy. If we're in the forked controller code and we take a signal,
> > we end up calling back into the forked controller code. Suddenly the
> > controller code needs sigprocmask() all over the place or we run the
> > risk of racing against ourselves in signal context.
>
> It was protected by "processing_signal". It's impossible for the
> second signal to get back into the forked controller code.
Angus, this has *nothing* to do with "second signals". Yes, we need to
take care of that issue, but it's not what I'm talking about. This is
about interrupting *non-signal context* code.
Can you resend me your patch?
regards
john
--
"Spammers get STABBED by GOD." - Ron Echeverri
