Kostik Belousov wrote:
I looked at the issue once more recently, and I propose the following
much less intrusive patch. It is somewhat hackish, but I think that
it would be good to have this working. Most other Unixes do have
working thread library after the fork. Any objections ?
diff --git a/l
On Wed, 18 Mar 2009, Kostik Belousov wrote:
I looked at the issue once more recently, and I propose the following
much less intrusive patch. It is somewhat hackish, but I think that
it would be good to have this working. Most other Unixes do have
working thread library after the fork. Any object
On Thu, Jan 22, 2009 at 12:42:56AM -0500, Daniel Eischen wrote:
> On Wed, 21 Jan 2009, David Schultz wrote:
>
> >I think there *is* a real bug here, but there's two distinct ways
> >to fix it. When a threaded process forks, malloc acquires all its
> >locks so that its state is consistent after a f
On Thu, Jan 22, 2009 at 12:42:56AM -0500, Daniel Eischen wrote:
> On Wed, 21 Jan 2009, David Schultz wrote:
>
>> I think there *is* a real bug here, but there's two distinct ways
>> to fix it. When a threaded process forks, malloc acquires all its
>> locks so that its state is consistent after a f
On Thu, Jan 22, 2009, David Schultz wrote:
> If you can't implement functions that are required to be
> async-signal-safe like fork() and exec() without malloc(), then
> for now I guess we should go for something along the lines of what
> Brian is proposing. If the app programmer has taken special
On Thu, Jan 22, 2009, Daniel Eischen wrote:
> On Wed, 21 Jan 2009, David Schultz wrote:
>
> >I think there *is* a real bug here, but there's two distinct ways
> >to fix it. When a threaded process forks, malloc acquires all its
> >locks so that its state is consistent after a fork. However, the
>
On Wed, 21 Jan 2009, David Schultz wrote:
I think there *is* a real bug here, but there's two distinct ways
to fix it. When a threaded process forks, malloc acquires all its
locks so that its state is consistent after a fork. However, the
post-fork hook that's supposed to release these locks fai
I think there *is* a real bug here, but there's two distinct ways
to fix it. When a threaded process forks, malloc acquires all its
locks so that its state is consistent after a fork. However, the
post-fork hook that's supposed to release these locks fails to do
so in the child because the child pr
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
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
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 d
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
On Fri, Jan 09, 2009 at 09:39:08AM -0800, Julian Elischer wrote:
> Brian Fundakowski Feldman wrote:
>> On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
>>> Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
> On Thu, 8 Jan 2009,
On Fri, Jan 09, 2009 at 07:42:32PM +0200, Kostik Belousov wrote:
> On Fri, Jan 09, 2009 at 11:34:26AM -0500, Brian Fundakowski Feldman wrote:
> > On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
> > > Brian Fundakowski Feldman wrote:
> > >> On Thu, Jan 08, 2009 at 10:44:20PM -0500,
On Fri, Jan 09, 2009 at 11:34:26AM -0500, Brian Fundakowski Feldman wrote:
> On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
> > Brian Fundakowski Feldman wrote:
> >> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
> >>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for mall
On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
> Brian Fundakowski Feldman wrote:
>> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
>>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
>>>
It appears that the post-fork hooks for malloc(3) are somewhat br
On Fri, 9 Jan 2009, Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to go
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to go
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
>
>> It appears that the post-fork hooks for malloc(3) are somewhat broken such
>> that
>> when a threaded program forks, and then its child attempts to go threaded, it
>> deadlo
In the last episode (Jan 08), Daniel Eischen said:
> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
> > It appears that the post-fork hooks for malloc(3) are somewhat
> > broken such that when a threaded program forks, and then its child
> > attempts to go threaded, it deadlocks because it al
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to go threaded, it
deadlocks because it already appears to have locks held. I am not familiar
enough wi
23 matches
Mail list logo
