From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] split __libc_start_main.c into two files (Wasm)
Date: Fri, 15 Dec 2017 12:23:53 -0500 [thread overview]
Message-ID: <20171215172353.GL1627@brightrain.aerifal.cx> (raw)
In-Reply-To: <HE1PR0502MB38831E8472815333D7449B91E70B0@HE1PR0502MB3883.eurprd05.prod.outlook.com>
On Fri, Dec 15, 2017 at 01:04:14PM +0000, Nicholas Wilson wrote:
> Hi,
>
> On 15 December 2017 12:33, Szabolcs Nagy wrote:
> > why is exit ugly?
> > halting execution should not be complicated on whatever platform
>
> In WebAssembly, the runtime environment is (typically) a webpage.
> It's not clear what exit() would be expected to do to the webpage or
> Wasm module. The Wasm interpreter offered by browsers doesn't offer
> a way to cleanly exit/terminate a running WebAssembly function; the
> "trap" instruction to abort is the closest you could get.
>
> If you have some existing C code that you want to compile/port to
> WebAssembly, whatever the code previously expects to happen on
> exit() won't happen. It will need to be changed when ported to the
> web, the semantics of a Unix process and a web page are unavoidably
> different. For brand-new code specifically targeting a web page, you
> wouldn't deliberately add a dependency on exit(), because it's not
> clearly meaningful for a webpage.
>
> So, it's "ugly" to me because the lifecycle of the webpage is an
> awkward fit for exit(). We could bodge in some emulation, but it's
> just ugly to pull in the emulation when we don't expect it to be
> used. My preference is "you should only link in the hacks you rely
> on".
>
> It's not too bad - we will have to implement exit() emulation for
> legacy code, so I could live with it being linked in to every
> application. I just dislike hacks, and don't enjoy seeing them
> bundled into my own applications!
I don't see this as ugly at all -- the obvious behavior for exit is
for it to just go into a "halted" state. 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. None of this should involve significant
size/cost.
Rich
next prev parent reply other threads:[~2017-12-15 17:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-07 14:51 Nicholas Wilson
2017-12-07 17:03 ` Rich Felker
2017-12-15 4:19 ` Rich Felker
2017-12-15 11:34 ` Nicholas Wilson
2017-12-15 12:33 ` Szabolcs Nagy
2017-12-15 13:04 ` Nicholas Wilson
2017-12-15 17:23 ` Rich Felker [this message]
2017-12-15 17:43 ` Nicholas Wilson
2017-12-15 17:56 ` Rich Felker
2017-12-16 13:21 ` Nicholas Wilson
2017-12-19 1:08 ` Rich Felker
2017-12-19 11:04 ` Nicholas Wilson
2017-12-19 15:27 ` Szabolcs Nagy
2017-12-19 15:56 ` Rich Felker
2017-12-19 17:46 ` Nicholas Wilson
2017-12-19 17:54 ` Alexander Monakov
2017-12-19 18:03 ` Nicholas Wilson
2017-12-19 21:03 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171215172353.GL1627@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).