Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of evgueni.brevnov@gmail.com
 designates 64.233.182.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=rpJHNaA7DPXrlVLwmDSQBvahz4NtcVRrgDesix7DuxFjQwmbp+9/MXED6VyqQDvrxbnQuBsD0RqRgv3WjMdYc5xoZlm0b5X+Pog+N6iM3EsesMsTnogrmmHdPtBfBfpMgusUphib+3IUS920ki18lSY1v8fjbzH4Fr+n6emjQzA=
Message-ID: <e29119980611212142g32303f94u2d8c43320b4fdef3@mail.gmail.com>
Date: Wed, 22 Nov 2006 11:42:00 +0600
From: "Evgueni Brevnov" <evgueni.brevnov@gmail.com>
To: dev@harmony.apache.org, geir@pobox.com
Subject: Re: [drlvm][threading] Should hythread_monitor_init() aquire the
 monitor?
In-Reply-To: <45636681.9080001@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e29119980611100645g629764d7xf5c72f78090bea81@mail.gmail.com>
	 <e29119980611162148x5dd54c56q8d43a39aee6a68a9@mail.gmail.com>
	 <e29119980611162219k29debf7dh58d62502efee7509@mail.gmail.com>
	 <ejka65$n1f$1@sea.gmane.org>
	 <3ae04f990611172205j1391b1fdm63274d0b87397575@mail.gmail.com>
	 <45620264.2030505@pobox.com>
	 <20b5243b0611211007y469ec869re5d5d7c5862ea5bf@mail.gmail.com>
	 <45635CA8.8030303@pobox.com>
	 <20b5243b0611211230j6c4903d1pdd19ba201c296361@mail.gmail.com>
	 <45636681.9080001@pobox.com>

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