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


More information about the busybox mailing list