mailing list of musl libc
 help / color / mirror / code / Atom feed
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


  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).