On 12/26/13 14:41, Mrad Chems Eddine wrote:
On 26/12/2013 05:36, Rob Landley wrote:
Do you mind if I respost this answer to the toybox list?
Yes, of course do whatever you want with the post.
Once again, I'm amused that thunderbird wordwrapped the text below but
if you cut and paste the same wordwrapping it won't quite accept it
because Thunderbird!
Oh well, it's less incomptent than Balsa. (Which is saying _nothing_...)
On 12/24/13 15:35, Mrad Chems Eddine wrote:
> On 24/12/2013 04:17, Rob Landley wrote:
>>
>> Toybox isn't a C library, musl-libc.org is a C library. Toybox is an
>> implementation of various command line tools.
>
> Yes, I know that. My idea is to release a C library similar to Toybox to
> be used in a host application where it can execute Unix commands in
> process without the cost of a fork(), exec(), etc. instead of standalone
> binary like yours. What do you think?
Ah, you mean _shared_ library. Got it.
In theory, some commands may be run nofork, meaning they run in the same
process context and return without leaking resources.
In practice, that's a fairly smallish number of the total. I have vague
plans to make more of them work like that, but at the moment commands
often leak memory and filehandles and memory mappings and such and
expect exit() to clean up after them.
Also, the response to errors is to exit via error_exit() and such. (Most
of the lib/xwrap.c functions exit on error instead of returning, that's
what the x prefix means.) Now I made error_exit() call xexit() instead
of exit(), whih has an option to longjmp() back to the caller instead of
exiting. But nothing's particularly using that at the moment (when i get
back to toysh, that's on the todo list).
And this is why the leaked resources are hard to fix, because if you
abort in the middle of a command, how do you clean up its leaked memory
and filehandles and such? (I have some ideas, but they're fairly
intrusive. I could wrap/track all the resource allocations, do brittle
groveling through /proc to find and free stuff, have the longjmp return
to cleanup code...)
Combining fork() with a function call is more lightweight than exec(),
and exit() can still clean up after it. But it's not nommu friendly, and
if commands nest deeply (nice setsid detach...) it can eat who knows how
much stack. So maybe it needs some sort of recursion limit where it does
an exec() anyway...
It's possible that for gluing this into u-boot or something, exit()
could just be replaced with halt() as the errors are generally "this
should never happen, it's not recoverable if it does".
Do you mind if I respost this answer to the toybox list?
Rob
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
