harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Disher" <jmdis...@gmail.com>
Subject Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Date Tue, 21 Nov 2006 18:07:52 GMT
On 11/20/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> Can you illustrate what you are talking about w/ a pointer to code?  We
> have some very concerning issues re signals, and I never could grok how
> J9 + classlib didn't have problems....

Without getting stuck in the specific line-by-line details of this, the idea
of chaining signal handlers essentially comes down to using an internal
handler registration interface so that components can register a handler
with an internal master signal handler and it (ie:  the port library, or
wherever you want it managed) would make sure that the user component
handler gets called when the signal is triggered.  This means that the
top-level signal handler - which is actually registered with the OS - is
created lazily within the internal master handler component.  When the
signal occurs, the master handler is invoked by the OS and it simply calls
all the handlers registered with it according to a defined ordering.  There
is also the issue of whether or not you want the chaining from one handler
to the next to be implicit or whether the signal handler has to decide (this
may be valuable in that you could allow a signal handler to be temporarily
installed to wrap a dangerous operation and the handler could opt not to
chain to the other handlers, thus shielding the rest of the VM from the
dangerous operation without it even needing to be aware of what happened).

There is also the possibility to apply some symbol over-riding tricks so
that foreign natives will be forced to use the mechanism in the VM even
though they thought that they were calling the normal system signal or
sigaction (note that things like this are pretty dangerous, though, and will
limit the scope of responsibility which you can push onto the user handlers
- ie:  chaining requirements or unregistration, etc - so it probably isn't a
good idea).

I am not sure if the mechanism that we use in the VM was released as part of
our Harmony contribution but it does specify a way that multiple handlers
can co-exist so we don't constantly have handlers from one component being
over-written by another.  As Angela mentioned, there is also a provision to
ensure that we don't over-write pre-existing external handlers.

Is that the kind of information you were looking for?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message