Date: Thu, 16 Sep 2004 17:01:12 -0700 From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: SIGILL @ pthread_create() after execv -FIXED- Message-ID: <414A2948.9000900@elischer.org> In-Reply-To: <Pine.GSO.4.43.0409161929250.26414-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0409161929250.26414-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote:
>On Fri, 17 Sep 2004, David Xu wrote:
>
>
>>Daniel Eischen wrote:
>>
>>
>>>We do that in fork(). Is execv() not being done after a fork()?
>>>
>>>
>>>
>>>
>>Joost calls execv() directly in threaded process, he did not go through
>>fork() ->execv() path.
>>
>
>Yes, Julian just emailed me similarly. In that case, I think we need
>to wrap execve() and set the kernel signal mask to the threads signal
>mask. We don't need all the single threading stuff that is in our
>wrapped fork(); just __sys_sigprocmask() should be sufficient. Right?
>
We would need to ensure that there is no chance that we could be
switched to another kernel thread between the two calls.
In general I'd prefer it if we had a way that worked even if the
userland screwed up..
execve is often a way in which daemons recover when they feel that they
have messed up in some way...
e.g.:
panic()
{
log("help I've fallen over and I can't get up");
execve( me, argc, argv, envpp); /* or whatever the args are ..ok
so I need to write more userland stuff */_
}
do we trust userland that much?
does the signal therad just enable ALL signals?
does it not maks those for which we have no consumers?
I'd still prefer to do things that work for libthr as well as libpthread.
_
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?414A2948.9000900>