So GNU/Linux glibc posix_spawn() is still violating the standard here?
No, it still does not pass the posix_spawn() parts of the POSIX
VSX-PCTS2003 test suite, for exactly the reasons Glenn listed in his
previous email.
spawn iffe tests have been moved to src/lib/libast/features/spawn to make
monitoring this a bit easier (results in arch/*/src/lib/libast/FEATURE/spawn)
and the tests have been annotated to list the exact reason for rejecting
posix_spawn()
src/lib/libast/misc/spawnvex.c was relaxed to use posix_spawn() in some cases
where _lib_posix_spawn=1 (posix_spawn() works but exits 127 on ENOEXEC)
sh implementations would use the spawnvex() SPAWN_EXEC flag to disable that
so they differentiate ENOEXEC from other exec errors -- this means that
ksh will only use posix_spawn() implementations that iffe _lib_posix_spawn=2
I'll restate why posix_spawn() exit code 127 on ENOEXEC is usesless for sh:
(1) there is no way for the parent to know how long to wait for the
child process exit code check -- how can the shell implement &?
* it can't block all other operations waiting for a bad exit status
* it can't really proceed with other children -- if 127 comes in later,
its too late to retry as a shell script
(2) exit code 127 is in band -- a user process can exit with that code
how can the parent differentiate that?
I don't see how this is useful, too.
But I do not understand why Solaris and the other Unix implementations
have a posix_spawn() implementation which apparently works with
ksh93u+. Why can't the glibc developers just clone this behaviour
(which appears to be mandated by POSIX and the POSIX VSX-PCTS2003 test
suite) and not insist on their world view of posix_spawn() which is so
far away from sanity and doesn't allow the implementation of real
world consumers.
to make the exit 127 implementations useful would require a portable
posix_is_executable(path) that would do the exec mode/perm checks along
with the object magic number checks -- a shell implementation would then
call this before posix_spawn() -- but then how much would this cut into
the savings of posix_spawn() over [v]fork()/exec()
posix_spawn() saves a lot of work in the kernel when it is implemented
as a syscall - it saves all the overhead of a full vfork() and exec()
will require to first create a whole child process with the parents
attributes and then change most of the attributes later. posix_spawn()
creates a whole new child process with the *selected* attributes and
that's all. That's a lot less parent-child communication and traffic.
Michal, does RH have a bugzilla report for the posix_spawn()
conformance issues? Or should I forward this to the LSB, since this
appears to be a glibc conformance violation?
Hi Cedric,
there is no bugzilla report for posix_spawn. From what I found in posix
papers, posix_spawn acts exactly as required. The only thing is that
paper says "implementations are permitted (and encouraged) to provide
more detailed failure information to parent process". So, there is no
posix violation, (or at least I was not able to find any).
It was also mentioned that it does not pass posix test suite.
Unfortunately, I was not able to find more, because this test suit is
not publicly available. And even if it was, I still won't have anything
to push glibc maintainers with, because there is no conflict with
mandatory part of posix_spawn specification. I don't argue whether
present behavior of posix_spawn is useful or useless. My attempts to
convince some people who are able to change anything were futile.
These guys are really conservative. Most of the time, it's good
characteristic for developer of core part of a system, but sometimes
it's not.
Glibc maintainers are best targets of email requiring posix_spawn
changes. Maybe if more people asks for change, they will change it.
Again, you use "violation" a lot, but I was not find any proof of
violation per se.
Michal
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
