[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: full moon, vm status update
From: |
Julian Graham |
Subject: |
Re: full moon, vm status update |
Date: |
Thu, 16 Oct 2008 01:35:02 -0400 |
Hi Andy,
> My current speculation is that when you compile --with-threads, as I
> do, that the socketpair between the signal receiving thread and the
> main thread is not closed after the fork, therefore signals in the
> child might reach the parent or vice versa, causing random code to
> run which itself might cause VM problems.
>
> Julian: if you have read this far and have the cycles, can you say
> something about the state of the signal socketpair after a fork?
Well, yes, that's possible; the signal handling system certainly isn't
aware of forking. But since only the thread calling fork() gets
created in the child process (and the signal delivery thread should
never fork), errant signal propagation would only be one-way -- in the
child-to-parent direction. I think I'm missing a little context,
though. Is forking (without doing an execve) something that happens
during compilation of VM code? What should the behavior be in this
situation? If the child process doesn't need async support, I guess
it could close the write end of the signal pipe, but that seems...
wrong, somehow.
Regards,
Julian
- full moon, vm status update, Andy Wingo, 2008/10/15
- Re: full moon, vm status update,
Julian Graham <=
- Re: full moon, vm status update, Ludovic Courtès, 2008/10/16
- Re: full moon, vm status update, Andy Wingo, 2008/10/16
- Re: full moon, vm status update, Neil Jerram, 2008/10/18
- Re: full moon, vm status update, Neil Jerram, 2008/10/27
- Re: full moon, vm status update, Andy Wingo, 2008/10/31
- Re: full moon, vm status update, Ludovic Courtès, 2008/10/31
- Re: full moon, vm status update, Andy Wingo, 2008/10/31