[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Dec 2017 17:43:33 +0000
From: Nicholas Wilson <nicholas.wilson@...lvnc.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: [PATCH] split __libc_start_main.c into two files (Wasm)
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.
> 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.
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.
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.
I'll revert the change on my branch. Thanks for discussing it.
Nick
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.
