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 Sun, 03 Dec 2006 23:26:20 GMT


Evgueni Brevnov wrote:
> 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)

(I have weird problems with mail - messages seem to come late... hence 
the late response)

A JIRA isn't a bad place to start.  Wanna create it? :)

I think the first thing is getting an understanding of what we already do...

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