Hallo Denys!
> Yes. As soon as process terminates. That's the problem:
I assumed, you asked how that feature is implemented. I didn't want to
discuss every whistle and bell of programming under a Unix like
operating system ... or about the topic of Unix philosophy.
The way described is the way this feature has been implemented sins
years and it worked without any known troubles. And this is even older
than Linux. Before /proc/self/fd/NNN there was /dev/fd/NNN, implemented
either as a library hook to the open() call or as a special character
device which used the minor number as file descriptor number. Despite
those minor differences it worked the same way. Any
open("/proc/self/fd/NNN" or "/dev/fd/NNN",...) behaves like a dup(NNN).
As long as you want the name "/proc/self/fd/NNN" point to a valid file
or stream YOU HAVE TO LEAVE that file descriptor open. As soon as you
close that file descriptor the name looses it's validity. Not only, that
it is no longer possible to open that file again, it may even point to a
different file unexpectedly ... and that could be disastrous ...
intentionally not what you want. That is, why the file still needs to be
open, until the end of life time of the process. Or in other words, that
the program doesn't know it has the file open another time, is the
fundamental behind this type of feature and its implementation.
> what if process *does not yet terminate*, but wants to close
At this point we are going to discuss about Unix philosophy. A program,
that doesn't yet terminate and counts on the function of signaling EOF
on pipes is a daemon or at least a long lived program. Such programs
have to follow special restrictions and strategies to be called well
believed.
Have you ever seen the following code fragment (or something similar) in
programs?
for( i=getdtablesize(); i > N; ) close( --i );
What does you think is the reason for this code? It is to close all open
file descriptors passed by the shell, which are not handled in the
program itself. That are not only file descriptors passed explicitly,
also those that have been placed outside of the visible scope of shell
file descriptors. Any long lived program has to do something like this.
Preferably after opening any files, passed as arguments from the shell
or you are not able to use this pipe substitution technique (the reason,
why process substitution doesn't always work as expected on such programs).
> 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. 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.
> 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! 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 ... but that was never the intention to do that. In some
shell implementations it could even be possible, that the writing end of
the pipe is hold open within the shell itself, closing the pipe as soon
as the command that contain the substitutions terminates ... and not
earlier!
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.
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
