Return-Path: 
 <dev-return-21836-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org>
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 51767 invoked from network); 15 Dec 2006 19:12:45 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 15 Dec 2006 19:12:45 -0000
Received: (qmail 66018 invoked by uid 500); 15 Dec 2006 19:12:49 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 65972 invoked by uid 500); 15 Dec 2006 19:12:49 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@harmony.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@harmony.apache.org>
List-Post: <mailto:dev@harmony.apache.org>
List-Id: <dev.harmony.apache.org>
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 65963 invoked by uid 99); 15 Dec 2006 19:12:48 -0000
X-ASF-Spam-Status: No, hits=0.6 required=10.0
	tests=FUZZY_VLIUM,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: domain of alin.harmony@gmail.com
 designates 66.249.92.170 as permitted sender)
Received: from [66.249.92.170] (HELO ug-out-1314.google.com) (66.249.92.170)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Dec 2006 11:12:46 -0800
Received: by ug-out-1314.google.com with SMTP id j3so859598ugf
        for <dev@harmony.apache.org>; Fri, 15 Dec 2006 11:11:17 -0800 (PST)
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=kntiwOhaBaFWGAWuX/+lkPiDdnoOSz2yHcom9kvd9B1xnENGPYAyjqzWSGMUugm/iWdJMWJj//kvVN27UIY+tz7gUEP0+66IuZ4toMFWtpJZIwvdSQbae/f+2DF+ItCvuMaRxviDRgOUFQdy3Z3Ckc9cOxVtlk6Qrvb4UWYogT8=
Received: by 10.82.113.6 with SMTP id l6mr95414buc.1166209877052;
        Fri, 15 Dec 2006 11:11:17 -0800 (PST)
Received: by 10.82.135.4 with HTTP; Fri, 15 Dec 2006 11:11:16 -0800 (PST)
Message-ID: <3ae04f990612151111u58b53f25tf9cc7a0ae64bc96d@mail.gmail.com>
Date: Fri, 15 Dec 2006 14:11:16 -0500
From: "Angela Lin" <alin.harmony@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][shutdown] Part2: How to shutdown native threads?
In-Reply-To: <e29119980612070331hce75674w2214d49e2475f3ae@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e29119980612070331hce75674w2214d49e2475f3ae@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

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?

Does the shutdown callback have to be called on a live thread?
The shutdown callback had better be threadsafe.

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.

In practice, we've had a lot more trouble with daemon threads.

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.