harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Date Wed, 22 Nov 2006 05:42:00 GMT
Geir,

Besides rethinking how VM uses SIGUSR2 we need to look closer into how
VM deals with signal handlers. As Jeff described above this is a very
delicate place. I'm almost sure DRLVM needs changes in this area.
Could you suggest the best way to keep this on track? (TODO list,
JIRA, or just a head)

Thanks
Evgueni

On 11/22/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> 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.
>
> geir
>
>
> 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.
> >> >
> >>
> >
>

Mime
View raw message