On Tue, Sep 7, 2010 at 1:40 AM, Harald Becker <[email protected]> wrote:
>> The wrong thing is that it waits for three seconds.
>> In this construct:
>>
>> producer | consumer
>>
>> when producer closes its stdout, consumer will see EOF
>
> Under the Unix philosophy, stdio is never closed explicitly.
Says who?
> Formerly
> there existed even library and/or kernel versions that just returned
> zero if you specified a file descriptor number below 3 to close(). Which
> was the reason, why you couldn't close/open stdio directly and it had to
> be done using dup2() or a special FORCE flag at the open call. So
> producer won't ever be possible to close stdout explicitly to signal EOF
> to consumer. EOF on that pipe is signaled as soon as producer has it's
> work done, that is it exits.
>
> ... else you are looking to implement a daemon feature using shell
> functionality. Which isn't the expected way. Keep in mind, we don't
> discuss the topic if this makes any sense. We just talk about how this
> has been handled sins the beginnings of Unix like operating systems.
You would not be able to talk your way out of the fact that leaving
a stray open descriptor for your child processes is a bug,
not a feature.
>> For example, alternate implementation with named pipes in
>> e.g. /tmp will not have this peculiarity (but will have other
>> problems).
>
> That's the/a reason why named pipes exist and have been used in those
> situations. But that has nothing to do with this process substitution
> feature.
>
> Despite this, I think your mistake is your assumption that <(producer)
> is using this technique. Here stdout of producer is connected to the
> write end of the pipe and the read end of the pipe is opened with
> /proc/PID/fd/NNN. That is, closing stdout will work as expected to
> signal EOF on the pipe, because producer doesn't has the writing end of
> the pipe open a second time!
Yes, in this case the leaked descriptor will be in consumer part.
> Only in >(consumer) the writing side of the
> pipe gets opened using the /proc/PID/fd/NNN technique, that is it has
> the writing end open twice and can't signal EOF to the consumer using a
> simple close...
Yes.
> but that was never the intention to do that.
You are creating arbitrary rules for the programs to follow just in order
to hide the fact that shell left an extra open descriptor.
Once on lkml one guy was working on some O(1) algorithm meant
to speed up open(). One thing which was an obstacle preventing him
from developing his algorithm is that open() must always return
the lowest free fd. The guy ranted that this is a stupid restriction,
that open() should have been defined to return an opaque handle,
without any ordering.
Then Linus came on the thread and said that breaking the Unix API
convention just to satisfy a pet project needs is (a) not going to happen
and (b) is "morally" wrong - it will create problems for *other* people
while allowing you to "solve" yours.
Eventually, the guy did find a way to write fast algorithm which
preserves the rule.
> Could it be possible, that we were looking for different features? So
> can you please clarify, what you are really looking for ... may be I
> missed something.
I don't look for anything. Currently I work on fixing ${var/pat/repl}
wrt backslash escaping in ash and hush. I do not yet work on
implementing <>(list) stuff. I will likely implement it the bash way
when the time comes (or when someone will send the patch ;),
but I will conceptually unhappy about the leaked descriptor.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
