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