Article on Unixlib

Alex Waugh alex at alexwaugh.com
Tue Feb 1 06:34:39 PST 2005


Nick Burrett wrote:

> 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 the module was replaced, what would happen to the mapping data? The 
current SUL avoids this problem by refusing to die if there are clients 
still registered, which I think is an acceptable solution.

>>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'.

Maybe. But there are also the mmaped DA's as well. I'll make sure it is 
not impossible to add if I don't add it initially.

>>>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.

So it does. This isn't a problem currently, as the parent cannot die 
before the child, but if we were to extend things with John's idea of 
using a separate wimp task then it might become a problem. We can either 
get SUL to update the ppid in the process struct of all children when 
the parent dies, or make it into a function. I think making it into a 
function may be simplest, and at least leaves more options open for the 
future.

>>>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.

Pretty much all of them call back into the application to deliver the 
signal at some point.

Alex

-- 
Alex Waugh                                           alex at alexwaugh.com

PHP, Roots, Subversion, WebJames and more from http://www.alexwaugh.com/





More information about the gcc mailing list