Allow creating a NaClAppThread without creating a new host OS thread

Allow creating a NaClAppThread without creating a new host OS thread

Split the thread-launching part of NaClAppThreadMake() into a separate
function, NaClAppThreadSpawn().

This is intended so that an embedder of NaCl can run untrusted code
without the overhead of creating a new host OS thread.  I have added
an example of this to tests/minnacl.

 * This means that an embedder might leave NaClAppThread's "thread"
   field uninitialized.  I have added a "host_thread_is_defined" field
   so that the thread suspension code doesn't use an undefined
   "thread" value accidentally in this case, and so that NaClAppThread
   is freed correctly if NaClThreadCtor() fails.

 * Rename NaClAppThread's "thread" to "host_thread" for greppability.

 * Rename NaClThreadLauncher() to NaClAppThreadLauncher() for
   consistency.

 * Split out NaClGetInitialStackTop() from NaClCreateMainThread() to
   avoid duplicating its logic in the test.

BUG=https://code.google.com/p/nativeclient/issues/detail?id=3223
TEST=run_minnacl_test

Committed: https://src.chromium.org/viewvc/native_client?view=rev&revision=10475

[bsy, 2012-12-17 21:02:05]

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
File src/trusted/service_runtime/linux/thread_suspension.c (right):

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
src/trusted/service_runtime/linux/thread_suspension.c:254:
CHECK(natp->host_thread_is_defined);
if we are trying to make it so that embedders can do other forms of threading,
shouldn't we provide an embedding interface for suspending threads in an
embedding-specific manner?  we should have a proper well defined contract for
what that means, of course.

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
File src/trusted/service_runtime/nacl_app_thread.c (right):

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
src/trusted/service_runtime/nacl_app_thread.c:207:
NaClMutexDtor(&natp->suspend_mu);
this is dead?

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
src/trusted/service_runtime/nacl_app_thread.c:256:
NaClThreadDtor(&natp->host_thread);
if an embedding-supplied thread, there should probably be a callback here (or
elsewhere, e.g., in the thread exit path) to let the embedding environment know
that the thread is available for re-use (or the thread will actually exit), etc.

[Mark Seaborn, 2012-12-17 22:30:14]

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
File src/trusted/service_runtime/linux/thread_suspension.c (right):

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
src/trusted/service_runtime/linux/thread_suspension.c:254:
CHECK(natp->host_thread_is_defined);
On 2012/12/17 21:02:05, bsy wrote:
> if we are trying to make it so that embedders can do other
> forms of threading, shouldn't we provide an embedding interface
> for suspending threads in an embedding-specific manner?  we
> should have a proper well defined contract for what that means,
> of course.

For the embedder I'm prototyping at the moment, there's no need
for thread suspension.  The prototype runs on Linux and it just
uses a single thread; untrusted code is now allowed to create new
threads.

But if an embedder does want its thread to be suspendable, it can
set host_thread to the current thread and set
host_thread_is_defined=1.  Before tearing down the NaClAppThread,
it can set host_thread_is_defined=0 to take back
ownership.  (When this functionality is needed, we can add a
function to nacl_threads.h for getting the current thread.)

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
File src/trusted/service_runtime/nacl_app_thread.c (right):

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
src/trusted/service_runtime/nacl_app_thread.c:207:
NaClMutexDtor(&natp->suspend_mu);
On 2012/12/17 21:02:05, bsy wrote:
> this is dead?

Good point.  Removed.

https://codereview.chromium.org/11543028/diff/15001/src/trusted/service_runti...
src/trusted/service_runtime/nacl_app_thread.c:256:
NaClThreadDtor(&natp->host_thread);
On 2012/12/17 21:02:05, bsy wrote:
> if an embedding-supplied thread, there should probably be a
> callback here (or elsewhere, e.g., in the thread exit path) to
> let the embedding environment know that the thread is available
> for re-use (or the thread will actually exit), etc.

Not necessarily.  If the embedder implements its own set of syscalls, it knows a
thread is finished with.  In the case of my prototype, I don't intend to allow
use of the regular exit() and thread_exit() syscalls.

[Mark Seaborn, 2012-12-18 23:49:30]

I have filed this issue to give more context on the design:
https://code.google.com/p/nativeclient/issues/detail?id=3223

Please take a look.

Mark

[bsy, 2012-12-19 00:07:09]

one nit.  o/w lgtm.

https://codereview.chromium.org/11543028/diff/19001/src/trusted/service_runti...
File src/trusted/service_runtime/nacl_app_thread.h (right):

https://codereview.chromium.org/11543028/diff/19001/src/trusted/service_runti...
src/trusted/service_runtime/nacl_app_thread.h:181: uint32_t       user_tls2);
please annotate w/ NACL_WUR

[Mark Seaborn, 2012-12-19 00:54:18]

https://codereview.chromium.org/11543028/diff/19001/src/trusted/service_runti...
File src/trusted/service_runtime/nacl_app_thread.h (right):

https://codereview.chromium.org/11543028/diff/19001/src/trusted/service_runti...
src/trusted/service_runtime/nacl_app_thread.h:181: uint32_t       user_tls2);
On 2012/12/19 00:07:09, bsy wrote:
> please annotate w/ NACL_WUR

Done.