Article on Unixlib

Nick Burrett nick at
Tue Feb 1 05:44:45 PST 2005

Alex Waugh said:
> Nick Burrett wrote:
>> My thoughts are that we should do all referencing using a process id,
>> allocated by the SUL.
> We could say that the process id is the same as the address of the
> process structure. Otherwise SUL would have to map from process id to
> the address of the structure (eg. searching a linked list for it) which
> would add extra complication and be less efficient.

If the application contains a pointer reference to a UnixLib structure
stored in RMA, then we could run into difficulties if the user RMUpdates a
new version of the UnixLib module, or re-initialised it.  The address of
the modules private data might change, breaking all application references
to it.

A mapping maintained by UnixLib module could alleviate this.

> If we do duplicate the DA, the we will always need to kill it on an exec
> (either we are after a fork, in which case it is a duplicate, or we are
> not after a fork, therefore it is the only copy but whole process is
> being replaced so it needs to be killed anyway).

I think Linux improves on this inefficiency by using copy-on-write pages.

> I agree we do need to duplicate it if we want to be completely accurate.
> My point was mainly that all current programs that work correctly with
> using vfork would be unaffected, so it would only affect new prgrams
> that currently do not work correctly, in which case is it really
> necessary to go to the effort of supporting duplication of the DA when
> we could just insist the these new programs use the wimpslot for the heap.

Mileage may vary.  If we can find that we can get away with not doing it,
then that's ok with me.  However, we should at least allow for the
necessary code to be added in the future.  As for effort, I'm not sure it
would be that much, since we "just" create a new DA and do a 'memcpy'.

>> I wonder whether we should call the SUL to tell us the parent pid, as
>> this
>> could change without the child's knowledge.
> SUL will initialise the parent pid when the process is created. Under
> what circumstances can the parent pid change after that? (I thought it
> was constant).

What about when a child becomes unattached from it's parent process i.e.
daemonisation ?  If the parent process is then killed off, what parent pid
goes the daemonised child then have.

I thought under that circumstance, the daemonised child gets the parent
pid of 'init', which is 1.

>> One question from me: should we move _signal.s into the SUL ?  These are
>> functions that are most required to be correct and stable in the event
>> of
>> memory corruption and other types of failure.
> If we move _signal.s, what else would we have to move?

I was hoping we could just move the __h_sig* functions.  Probably can't
move anything that calls back into the user application though.


More information about the gcc mailing list