[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171215175657.GM1627@brightrain.aerifal.cx>
Date: Fri, 15 Dec 2017 12:56:57 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] split __libc_start_main.c into two files (Wasm)
On Fri, Dec 15, 2017 at 05:43:33PM +0000, Nicholas Wilson wrote:
> On 15 December 2017 17:23, Rich Felker wrote:
> > I don't see this as ugly at all -- the obvious behavior for exit is
> > for it to just go into a "halted" state.
>
> There is no builtin lifecycle for that in web browsers, but we can emulate it.
There's always a trivial halted state: for(;;); Presumably there are
also more efficient ones. :-)
> > This is what you generally
> > expect on embedded C implementations with no OS, or if pid 1 exits on
> > a unix-like system. If you don't yet support thread creation, all it
> > has to do is something like for(;;) wait_for_something(); or similar.
> > Once you have threads, you may need some nontrivial work to ensure
> > that all threads enter a halted state, or it might just be as simple
> > as stopping the interpreter.
>
> We certainly can't do an infinite loop (who wants tabs in their
> browser to lock their CPU at 100%?) - and there's no way to wait on
> anything in Wasm since it's single-threaded.
Wait doesn't require a thread. It could be waiting for data from a
source that will never have data, waiting for elapse of a certain
period of time (e.g. for(;;) sleep(1000000000);), etc.
> A trap is the only way to report to the interpreter that it should
> stop execution. It's workable, although awkward. (JavaScript can
> also throw exceptions, but Wasm code will soon be able to catch
> those, so a trap is I believe the only uncatchable exceptional
> condition.)
>
> It will look something like defining "__syscall_exit() {
> __builtin_trap(); }" for Wasm.
Sounds ok.
> If you really don't want to split the translation unit, I can live
> with it, although it doesn't seem like a big request, since it's not
> changing the code at all, just giving independent linkage to two
> different functions.
Adding a new interface boundary/contract for a particular arch _is_ a
big request, one of the biggest types. It's a permanent added
constraint that has to be considered in future modifications to the
code. Probably the only bigger type is adding a new public (to
application) interface boundary/contract.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
