Re: Patch libpthread_globsigdisp
>From: Samuel Thibault <sthibault@debian.org>
>Yes, except that I see a danger: what if a signal is sent to the
>thread around the time it is calling pthread_exit()? I don't
>remember the details, but I guess if that happens after the call to
>_hurd_sigstate_delete(), the sigstate will be reallocated and thus
>leaked (or some other bad such thing).
That would explain it. The whole point is to not be leaking resources,
so the call goes where best to ensure that. Thank you.
>> I'm sorry if I am nit-picking. The patch came up as a problem source
>> in the move of the hurd to pthreads (the patch itself isn't the problem,
>> but its consequences introduce a problem).
>Which problem?
When trying to boot using pthread ext2fs.static, it would always
segfault. Here's what Richard had to say:
>The problem is that _hurd_global_sigstate is NULL at this moment. It's
>part of the global signal dispositions patch, and migrating Hurd servers
>to pthreads means they now have to behave more POSIXely. The global
>signal state is normally created by _hurdsig_init, but only if the proc
>server exists (see hurd/hurdinit.c). Obviously, when used as a root file
>system, this isn't the case.
He then "fixed" this, as evidenced by him having pthread hurd test
machines. Here's what he had to say about that:
>In the meantime, I merely made sigstate_is_global_rcv check that
>_hurd_global_sigstate isn't NULL. Now I have a subhurd completely
>populated by pthreads-enabled servers (libthreads.so.0.3 doesn't even
>exist any more).
I'll take that as a satisfactory answer to my question, I hope that I
answered yours. I've spent too much time looking at libpthread....
Thomas DiModica
Reply to: