from the ast/ksh perspective workarounds are a way of life
even if vendor bug fix turnaround is 6 months it may
take users years to upgrade to the fix
and we would need 1 head count to keep track of all the bugs
among all the vendors
we'll be happy to report problems and workarounds encountered building on ON
interested parties can translate those into official bug filings
and when the fix finally rolls back around the iffe configuration
workarounds will yield to the fix
so I have access to solaris { 8 9 10 11 } machines
how can I tell if any of them are ON?
also
I re-read the posix_spawn() standard and it is worded to
allow successful return to the caller, with a valid pid,
even when the executable encounters an exec error
in that case exit status 127 (normally "not found")
means "a fork or exec error", and the caller cannot
retrieve the real errno
I believe we can encapsulate the posix_spawn() call to
do an immediate waitpid(WNOHANG|WNOWAIT) to check for exit status 127
and interpret that to be ENOEXEC -- this may mask the real
fork/exec error that caused exit code 127, but posix_spawn() leaves
no recourse
its a shame the posix spec has this loophole that allows errno
to be thrown on the floor
but I think quality of implementation should push
posix_spawn() implementers to find a way to make posix_spawn()
fail immediately on exec error -- with real vfork this is possible
we've done it in the spwanveg() implementation that uses real vfork/exec
I haven't tested ENOEXEC regular executables on all architectures
but solaris 10 posix_spawn() returns success with exit status 127 (good)
and at least one linux returns success with exit status 0 (bad)
I'm modifying the iffe test to detect this and will report the results
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
On Tue, 31 Oct 2006 07:18:15 -0500 James Carlson wrote:
> Glenn Fowler writes:
> > so by empirical evidence two assertions flying on this thread are false:
> > (1) solaris posix_spawn() is ok to use
> > (2) solaris vfork() == fork()
> Time for a consolidation check. ;-}
> Things may be different in other consolidations, but within ON, it is
> not generally acceptable just to "work around" problems found in the
> system.
> The project team must (1) file a bug (or bugs) on the problems
> encountered with posix_spawn and (2) be ready to explain why fixing
> the problem or being dependent on the fix is not desirable.
> Though we all have our separate projects to work on, within ON we are
> collectively responsible for the quality and consistency of the code.
