Make it so that Parrot on RTEMS does not call the system exit()

[leto]

There are various ways to make this happen, and various levels of configurability, such as allowing a custom exit handler, but for starters, we just want Parrot on RTEMS to unconditionally not call the system exit() when shutting down, as this causes RTEMS to reboot.

Other tickets can be opened for a more features in the future.

Originally http://trac.parrot.org/parrot/ticket/1657

[leto]

exit() is called on line 96 of src/exit.c . A compile-time macro should be put in that calls exit() unless the current OS is RTEMS.

[bacek]

There is also some calls to exit inside src/gc...

[parrot]

>  There are various ways to make this happen, and various levels of
>  configurability, such as allowing a custom exit handler, but for starters,
>  we just want Parrot on RTEMS to unconditionally not call the system exit()
>  when shutting down, as this causes RTEMS to reboot.
Note that according to the docs all calls to exit or _exit are wrong.
The documented way to exit is to return control to whoever run the
first runloop on the main interpreter. The current behavior is wrong,
it breaks not only rtems, but embedding usages that wants to keep
running is spite of whatever happens in the parrot code.
So I think we must fix the full issue, not just making a special case for RTEMS.
--
Salu2

[jkeenan]

Commenters/committers:

Could we get an update on the status of this ticket?

Thank you very much.

kid51

[plobsing]

This is not an RTEMS-specific problem. Any embedding application (irssi, vim, apache, perl5, etc) also wants more control over what happens when parrot exits.

We should require a hook be installed on init by the parent application (and there is always a parent application, parrot.exe being a particularly simple one) to determine what happens in these cases.

[Whiteknight]

the exit function is now no longer called from within src/exit.c, and should not be (to the best of my knowledge) called from anywhere within Parrot. This is now a front-end issue. The question is, do we want to use the same frontend (frontend/parrot2/main.c) for these systems and put in an #ifdef around the exit() calls so we don't exit if the system doesn't support it, or should we create a separate frontend entirely for these embedded systems with their specific needs in mind?

[Whiteknight]

No, I was very mistaken. There are many calls to exit in the codebase. Several of them can probably be replaced with PANIC(), which currently falls back to exit() but which can be modified in the future. Several other instances can be replaced with Parrot_x_exit() or Parrot_x_jump_out(). I'm going to do some of that now.

[Whiteknight]

@DukeLeto: I'm putting together some alternatives now. Instead of calling exit(), we're going to use a macro called PARROT_FORCE_EXIT(x) in include/parrot/exit.h. What should this be, in RTEMS? Also, are there any defined macros we can use to determine whether we are compiling for RTEMS or not?