>No, this is while starting up, so we don't want to exit. The only reason >for the alarm() is that tcdrain() might hang because of flow control >issues according to Denys, and if that happens we just want to fall >through and tcflush().
Forgive my lack of paying attention, but then what is the point of the drain at all? It'll drain in its own time. The usual need for a drain is to prevent race conditions with a device close or mode change (like baud rate) that might chop off or mangle the pending output. Or is there some other race here? >And yes, STDOUT_FILENO would be somewhat clearer (but wouldn't matter as >we just did xdup2(0, 1)), but I kept it as STDIN to match the tcflush >just below. But tcflush of stdin throws away pending _input_, does it not? The fact that the two devices are connected together doesn't affect the semantics of fiddling with input versus output streams. I find it confusing to apply output ops to input streams, but that just happen to work given the setup circumstances. Makes things seem like they're trickier than they actually are, which is usually not a good thing. -- Jim _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
