On Fri, Sep 03, 2010 at 09:04:08PM +0200, Samuel Thibault wrote:
> Right, I believe it should be feasible to keep the signal sematic of
> libthreads and give the posix semantic to libpthread.
Yes, we should make libc manage a set of "process signal receiving"
threads, which would include the initi
Roland McGrath, le Thu 02 Sep 2010 19:52:42 -0700, a écrit :
> > Do you mean that there is some code relying on these Hurd semantics, and
> > that therefore we should not try to change them to match POSIX, except
> > maybe when the pthread functions are used?
>
> I mean the semantics are the seman
At Thu, 2 Sep 2010 19:52:42 -0700 (PDT),
Roland McGrath wrote:
>
> > Do you mean that there is some code relying on these Hurd semantics, and
> > that therefore we should not try to change them to match POSIX, except
> > maybe when the pthread functions are used?
>
> I mean the semantics are the
> Do you mean that there is some code relying on these Hurd semantics, and
> that therefore we should not try to change them to match POSIX, except
> maybe when the pthread functions are used?
I mean the semantics are the semantics and have been for 15+ years, and we
can't assume it's OK to just g
On Thu, Sep 02, 2010 at 05:15:04PM +0200, Jeremie Koenig wrote:
> Needs a second signal:
> $ ./testsigthread
> *kill*
> Unblocking now.
> *nothing happens, re-kill*
> Got it!
> Got it!
So this is a problem with libpthread rather than glibc (sigprocmask
handles this correctly). I'm testing a patch
On Thu, Sep 02, 2010 at 02:15:30PM -0700, Roland McGrath wrote:
> It's not an issue of fixes. The Hurd signal semantics are well-defined
> today. They are not the POSIX-1996 semantics in the presence of multiple
> threads per process.
Do you mean that there is some code relying on these Hurd sem
It's not an issue of fixes. The Hurd signal semantics are well-defined
today. They are not the POSIX-1996 semantics in the presence of multiple
threads per process.
On Thursday 02 September 2010 17:56:24 Samuel Thibault wrote:
> Signal handling is known to be crappy in glibc so it's not really a
> surprise. If you can find a fix, that's great, but Roland expected to
> rewrite the whole thing some day.
Actually I would prefer having a fix now to having a clea
It's not that it's a bug, it's that the Hurd has never had POSIX-1996
multithreaded signal semantics. The Hurd implementation predates those
specifications.
Jeremie Koenig, le Thu 02 Sep 2010 17:15:04 +0200, a écrit :
> I have been investigating why 'ant' hangs under GIJ when running
> external commands.
That's a very good thing to investigate, as it makes a lot of java
packages FTBFS.
> It turns out it is a bug in the way glibc handles signal delive
Hi,
I have been investigating why 'ant' hangs under GIJ when running
external commands. The problem is in Process.waitFor(), which hangs
because libgcj's ProcessManager thread never gets SIGCHLD. This can be
reproduced with the attached Test.java.
It turns out it is a bug in the way glibc handles
11 matches
Mail list logo
