harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angela Lin" <alin.harm...@gmail.com>
Subject Re: [drlvm][shutdown] Part2: How to shutdown native threads?
Date Mon, 08 Jan 2007 15:13:38 GMT
On 12/18/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> On 12/16/06, Angela Lin <alin.harmony@gmail.com> wrote:
> > On 12/7/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > >
> > > Thread creation and shutdown callback registration operations should
> > > be atomic. In other words, there should be no possibility to shutdown
> > > the thread between these two operations. Thus it seems to be
> > > convenient to pass shutdown callback as a parameter to the
> > > hythread_create & hythread_attach routines. It is how they will look:
> >
> > This seems reasonable, but can you please clarify what the shutdown
> > callback should do?
> >
> > Should it:
> > 1. Tell the thread to shut itself down?
> > 2. Tell the thread to clean up its resources?
> > 3. Clean up resources for the thread?
> > 4. .. some combination of the above?
>
> In my understanding it should do the 1) what implies 2).
>
> >
> > Does the shutdown callback have to be called on a live thread?
>
> I think it's pretty dangerous to execute a shutdown callback of the
> non-live thread. This callback may refer to a thread specific data
> which is only valid when thread is alive. And there is no need to
> execute the callback if the thread is already dead. So the answer is
> YES, our implementation should guarantee to call shutdown callback on
> live threads only.
>
> > The shutdown callback had better be threadsafe.
> Sounds reasonable to me.
>
> >
> > This API feels a bit redundant. Threads that know to do
> > hythread_attach(), or are hythread_create()ed, are usually VM helper
> > threads and we already have other ways to coordinate shutdown with
> > them. ... But this method is arguably more elegant.
>
> Sorry, I'm not aware about the alternative approach. Could you describe it?

Since, by definition, VM helper threads know about VM internals and, presumably,
have access to some shared VM data, you can use the shared VM data to coordinate
shutdown of the help threads. There's no standard approach.

>
> >
> > In practice, we've had a lot more trouble with daemon threads.
>
> Yes, I agree that daemon thread is another important part of the whole
> picture :-)
>
> >
> > Angela
> >
> > >
> > > /**
> > > <snip>
> > > * @param[in] callback when non null callback function is specified it will
be
> > > *    executed by hythread_cancel(hythread_t thread) to initiate thread shutdown
> > > *    sequence. If no callback is given then this thread doesn't have a chance
to
> > > *    cleanup its internals and will be terminated forcibly.
> > > *    Note that by the time of callback execution the VM  is already in shutdown
> > > *    stage thus not all services provided by VM are available. For example,
> > > *    any attempt to create a new java thread or attach the current one
> > > will fail.
> > > *
> > > * @return  0 on success or negative value on failure
> > > *
> > > * @see hythread_exit, hythread_resume
> > > */
> > > IDATA VMCALL  hythread_create (hythread_t *handle, UDATA stacksize,
> > > UDATA priority, UDATA suspend, hythread_entrypoint_t entrypoint, void
> > > *entryarg, hythread_shutdowncallback_t callback);
> > >
> > > /**
> > > <snip>
> > > * @param[in] callback <same as above>
> > > */
> > > IDATA VMCALL  hythread_attach (hythread_t *handle,
> > > hythread_shutdowncallback_t callback) ;
> > >
> > > Also registered shutdown callback should be taken into account by
> > > hythread_cancel(hythread_t thread) and called as appropriate.
> >
>

Mime
View raw message