On 03/27/2010 03:39 PM, Chris Pickett wrote:
> On Thu, Mar 18, 2010 at 4:41 PM, Darren J Moffat
> <darrenm at opensolaris.org> wrote:
>> What benefit does this case bring ?
>
> First at all you do not go through fork() and be a lot faster.
The intent appears to be better performance; generally a good thing.
I'm concerned about the implementation and its implications.
It seems to me that this is an example of all problems in programming
being an exercise in caching. The item being cached is a utility
executable, and the cache load time is during compilation of the
proposed new ksh93 implementation.
Unfortunately, the cache invalidation and/or reload is also the latter
time. I think this is a mistake. If I, with suitable permissions, cannot
replace the binary of a utility in the filesystem of my system and
get the expected changed behaviour, it is no longer Unix. This
is an architectural issue.
Gnu-ness or otherwise is not relevant to this argument.
As a possible alternate architecture, I suggest
1) kernel support for pre-linking arbitrary executables with
a running process, such that a call into such an executable image
does not require a system-call
2) kernel support for de-linking the above, from the running
process
3) means for a running process to be notified of changes to
the filesystem object backing an executable, without the
use of a system-call when no such change has been made
We've been into this area before. Let's not make such a mistake as vfork was
again.
--
Jeremy Harris
