harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Date Tue, 21 Nov 2006 20:08:08 GMT
Yes.  Thanks - does this mean that we can intercept and prevent "slow" 
system calls like select() from interrupting?

This is the key problem I'm trying to solve.  I suspect the answer is 
"yes" somehow, since we see no behavioral problems with J9 and the 
various socket calls in the Harmony classlib.


Jeff Disher wrote:
> 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?
> Jeff.

View raw message