[Bug 3547] shell read is maybe too safe
Laurent Bercot
ska-dietlibc at skarnet.org
Tue May 10 11:03:00 UTC 2011
> I think the solution, as I realized later, is to dynamically reassign
> your file descriptors not to clash with those used by the script
> (using dup).
Yes, that's a bit of work because all the internal fds have to be
carefully kept track of, but it's a sane solution indeed. Denys, what
do you think of a dynamically reassigned selfpipe/signalfd ?
> And of course make them close-on-exec so external
> commands never see them.
Of course. It was a painful bug in the early releases of ash: the fd
reading the script (which was set to 10) wasn't coe, so every command
in the script inherited it. I had a lot of trouble with that one bug
(filesystems failing to unmount without any obvious reason).
> The only bad things about pselect are those it shares with select,
> i.e. fd_set having a fixed size limit. Otherwise it's very nice.
Question of taste. I dislike having to think about signal masks when
I'm doing I/O.
> Actually thread may let you reduce the complexity. Most things that
> are complex without threads become easy with threads.
It's only true when
* you have a lot of complex, multi-state things happening in parallel
(to justify having several synchronous threads over a basic asynchronous
event loop)
* you have a lot of shared structured data that would make IPCs complex
(to justify a multi-thread model over a multi-process model).
I don't think the asynchronicity in a shell is complex enough to
warrant using threads. Shells are difficult to write, but the complexity
does not come from asynchronicity.
> But I'm quite aware that busybox is allergic to them. :)
And for good reason, I think. Threads have costs, especially in
maintainability. But I know it's a highly religious subject, so let's
not discuss that in this thread.
--
Laurent
More information about the busybox
mailing list