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:50:09 GMT
Yes.  I think I now understand why you don't have the same problems w/ 
J9 that we do w/ DRLVM.  I think :)

It think it's worth us revisiting how we're using SIGUSR2 in DRLVM and 
see if we can refactor along the lines of how you are using them in J9.

Thanks so much for the info.  This one has been bugging me for a while.


Jeff Disher wrote:
> No, this is a different mechanism.  Signal handler chaining and native to
> port signal number mappings are both done on the thread which receives the
> signal.  If that thread is the one which was in a select, then it has
> already been interrupted to run the master handler.
> My guess as to why you don't see these interruptions in the Harmony port
> calls when running with J9 is that, for the most part, our internal signals
> are synchronous so they are handled on the thread which causes them.  Even
> when we use asynchronous signals, we are usually using pthread_kill to send
> them to specific threads which we know to be blocked in an operation which
> is allowed to be interrupted (FYI:  these are not in port, hence why it
> doesn't already have logic for this).
> If you really don't want to be interrupted by an asynchronous signal during
> some operation, the only way may be to change the per-thread signal mask 
> for
> the duration of the uninterruptable code path.  At least then you would
> receive the signal at a deterministic point (the resetting of the signal
> mask) or it would be sent to another thread.
> Even that seems like a heavier operation than just allowing the call to be
> interrupted and deciding if you needed to handle the interruption or just
> resume (complications involving remaining timeout aside - they may make it
> easier to mask).
> Does that answer your question?
> Jeff.
> On 11/21/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>> 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.
>> geir
>> 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