[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Avoid passing autotest job fds to test groups.
From: |
Ralf Wildenhues |
Subject: |
Re: [PATCH] Avoid passing autotest job fds to test groups. |
Date: |
Wed, 21 Jul 2010 21:52:57 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
* Eric Blake wrote on Wed, Jul 21, 2010 at 08:22:15PM CEST:
> On 07/21/2010 12:06 PM, Ralf Wildenhues wrote:
> >> But maybe we want to do a global:
> >>
> >> for i in 3 4 5 6 7; do
> >> eval exec $i>&-
> >> done
> >
> > (why not just exec 5>&- 6>&- 7>&-?)
>
> Easier to extend if we wanted to clear out to fd 63 or some such (if seq
> were portable, then 'for i in $(seq 63); do...' would be easier than
> writing 60 >&- instances). But yeah, it makes more sense to only clear
> what we will explicitly use, rather than to clear arbitrarily high.
$ ksh -c '( exec 17>&-)'
ksh[1]: exec: 17: not found
ksh -c '( fd=17; eval exec $fd\>\&-)'
ksh[1]: eval[1]: exec: 17: not found
It is not portable to use fds higher than 9, and the above eval had
quoting problems too ;-)
> > We don't do anything with fds 3 and 4; either we consider them special,
> > then shouldn't close them for that historical reason, or we could just
> > use them for internal purposes. Or decide now not use them because
> > we've never done so (and our users may have come to rely on that fact).
>
> We also document that users cannot rely on shell 'exec 3>file' to be
> preserved over an exec*(2) call (that is, fds 3 or larger may be marked
> cloexec when opened by the shell), and that other shells explicitly
> close all inherited fds 3 or larger on startup (that is, even if an fd
> is not cloexec in the shell's parent, it might be closed rather than
> inherited to the shell script body). So, on thinking about it more,
> there is no portable way to write a test that relies on external
> inheritance of an fd >= 3 opened by the parent of the testsuite; and
> within a portable test, you can use only fds 3 or larger only so long as
> you stick to shell constructs (you can't expect your C program or a
> subsidiary script to see those fds unless you used the shell to
> duplicate it onto one of the 3 standard streams).
This paragraph assumes that the portability requirements of some user
package are roughly the same as those Autoconf assumes for itself,
right?
> > But anyway this still means that users wanting to pass extra fds to test
> > groups, should know that 5, 6, and 7 are reserved by Autotest, at least
> > for passing from outside the testsuite. And probably that 5 is better
> > avoided inside as well (I'm not sure if that's necessary, but it might
> > be at some point).
>
> Yeah, documenting that fd 5 is reserved for autotest logging may be
> worthwhile. But I don't see that holding up 2.67.
Of course not. Finishing 2.67 is more important than these details.
Cheers,
Ralf
- Re: testsuite failure - 193 parallel execution, (continued)
- Re: testsuite failure - 193 parallel execution, Paul Eggert, 2010/07/20
- Re: testsuite failure - 193 parallel execution, Eric Blake, 2010/07/20
- Re: testsuite failure - 193 parallel execution, Paul Eggert, 2010/07/20
- Re: testsuite failure - 193 parallel execution, Eric Blake, 2010/07/20
- Re: testsuite failure - 193 parallel execution, Ralf Wildenhues, 2010/07/20
- Re: testsuite failure - 193 parallel execution, Eric Blake, 2010/07/20
- [PATCH] Avoid passing autotest job fds to test groups., Ralf Wildenhues, 2010/07/21
- Re: [PATCH] Avoid passing autotest job fds to test groups., Eric Blake, 2010/07/21
- Re: [PATCH] Avoid passing autotest job fds to test groups., Ralf Wildenhues, 2010/07/21
- Re: [PATCH] Avoid passing autotest job fds to test groups., Eric Blake, 2010/07/21
- Re: [PATCH] Avoid passing autotest job fds to test groups.,
Ralf Wildenhues <=
- [PATCH] Plug race in parallel autotest., Eric Blake, 2010/07/20
- Re: testsuite failure - 193 parallel execution, Ralf Wildenhues, 2010/07/20
- Re: testsuite failure - 193 parallel execution, Eric Blake, 2010/07/20