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 20:30:44 GMT
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?

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.
> >

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