Hy,
Thanks for the great work.
I tested this new translator with pidof and killall5 and it works
fantastic. I hope it replaces the old procfs translator soon, because
the initscripts in Arch Hurd heavily depend on pidof.
Alexander Preisinger, le Thu 02 Sep 2010 09:46:18 +0200, a écrit :
> I tested this new translator with pidof and killall5 and it works
> fantastic. I hope it replaces the old procfs translator soon, because
> the initscripts in Arch Hurd heavily depend on pidof.
Well, as the previous procfs implem
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
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
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.
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 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.
* sysdeps/mach/hurd/pt-sigstate.c (__pthread_sigstate): Wake up the message
thread if any pending signals have been unblocked (code grabbed from glibc).
---
sysdeps/mach/hurd/pt-sigstate.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/sysdeps/mach/hurd/pt-sigstat
Jeremie Koenig, le Fri 03 Sep 2010 01:38:29 +0200, a écrit :
> + pending = ss->pending & ~ss->blocked;
> +
>__pthread_spin_unlock (&ss->lock);
>
> + if (! err && pending)
> +/* Send a message to the signal thread so it
> + will wake up and check for pending signals. */
> +__m
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
On Fri, Sep 03, 2010 at 02:14:30AM +0200, Samuel Thibault wrote:
> Jeremie Koenig, le Fri 03 Sep 2010 01:38:29 +0200, a écrit :
> > + pending = ss->pending & ~ss->blocked;
> > +
> >__pthread_spin_unlock (&ss->lock);
> >
> > + if (! err && pending)
> > +/* Send a message to the signal th
> 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
13 matches
Mail list logo
