Is fork() hook ever possible?

[Poul-Henning Kamp]

In message <20080917075513.GB55535 at nagual.pp.ru>, Andrey Chernov writes:
>On Tue, Sep 16, 2008 at 08:41:33PM +0000, Poul-Henning Kamp wrote:
>> In message <200809161628.54085.jhb at freebsd.org>, John Baldwin writes:
>> 
>> >The PID isn't the seed, he's using a PID change as a notification that the 
>> >process needs to do a re-stir the next time it wants a psuedo-random number 
>> >(b/c the PID change means it is now a new process).
>> 
>> Seems to be a vast overkill to me, in countless other contexts,
>> it is the responsibility of the programmer to do what needs done on
>> a fork, and I see no reason why this couldn't be likewise.
>
>The situation is not so simple since the library functions can call 
>ar4random() internally (like mktemp() family already and always does)

I have a really hard time seeing how this could become a performance
issue, ever.

The solution however, is simple: Just have these hidden library calls 
to arc4random call a wrapper function that does the pid check.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.