threaded, forked, rethreaded processes will deadlock
Daniel Eischen
deischen at freebsd.org
Wed Jan 21 15:36:01 PST 2009
On Wed, 21 Jan 2009, Brian Fundakowski Feldman wrote:
> On Mon, Jan 19, 2009 at 07:41:35PM -0500, Brian Fundakowski Feldman wrote:
>> On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote:
>>> Brian Fundakowski Feldman wrote:
>>> > Could you, and anyone else who would care to, check this out? It's a
>>> regression
>>>> fix but it also makes the code a little bit clearer. Thanks!
>>>>
>>>> Index: lib/libc/stdlib/malloc.c
>>>
>>> Why does malloc need to change for this? Unless there's a really good
>>> reason, I don't want the extra branches in the locking functions.
>>
>> Because malloc is the thing causing the regression. It is easy enough
>> to optimize out the one extra fetch and branch in the single-threaded case
>> if I can get some consensus that the fix to it is actually fine.
The changes to thr_fork.c seem gratuituous; they don't
affect any functionality, and I don't see the difference
between the flag saying "unlock the malloc mutex" or
"I was threaded". Clearly, it is set in "if (__isthreaded)",
so it is obvious that it indeed was threaded.
I can't speak to the malloc changes...
--
DE
More information about the freebsd-hackers
mailing list