[Bug threads/20291] Set scheduler-locking on doesn't work correctly with pthread_create

["martin.galvan at tallertechnologies dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20291

--- Comment #9 from Martin Galvan <martin.galvan at tallertechnologies dot com> ---
(In reply to Pedro Alves from comment #8)
> Baking in awareness of glibc's internals in order to let the child run a bit
> is not that appealing.

Agreed. That would be ugly.

> Note this sort of hang can happen when you step over _any_ function that
> blocks on some synchronization primitive (with schedlock on).

I'm going through the glibc code again and I'm kind of lost here. You said the
hang would arise because the parent thread would wait forever for the child to
release the lock. However, create_thread first locks pd->lock, and then calls
clone (through ARCH_CLONE), passing it the glibc-internal start_thread as
starting routine. start_thread, in turn, will try to lock that same lock,
blocking the child. The parent then has a chance to set some more stuff on the
child, and then it unlocks it so the child can go on and call its user-provided
routine.

What this means is, the child waits for the parent and not the other way
around. If schedlock somehow manages to prevent the child from ever being
scheduled, the parent shouldn't mind (unless of course the user later calls
pthread_join, but that's their problem :)).

In any case, I think you're right in that the parent might hang elsewhere. My
point was that it's a bad thing if it happens in library code, but the user can
reasonably be expected to be aware of this in their own code.

> What do you suggest gdb should do?

I'm not sure. I'm just starting to dwell in this part of gdb, so I'm gonna need
a bit more inspecting before I can make a proper suggestion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.