Article on Unixlib

John Tytgat John.Tytgat at aaug.net
Sun Jan 23 14:01:38 PST 2005


In message <31edf8304d.ajw498 at caramel.cp15.org>
          Alex Waugh <alex at alexwaugh.com> wrote:

> To put a bit more substance to my proposal, I think the process
> structure should be something along the lines of the following.
> [...]

The thing I'm still unsure of is if we really have a clear boundary
what will move into SUL and what not with your proposal.  E.g. I
understand that e.g. sys/_vfork.s will be part of it, but this imports
several variables and routines so how will SUL have access to them ?

> [...]
> One additional problem I forgot to mention that I want to solve is
> closing of file descriptors, which is currently based on the pid of the
> program that opened them. This is a bit simplistic, and breaks in some
> situations, so I'd like to change it to using a reference count. When
> the count reaches zero the underlying filehandle/socket will get closed.
> The file descriptors will continue to be manipulated by the program,
> SUL will only need enough knowledge to be able to duplicate them and
> increment the refcount on a fork.

That needs indeed some attention.

> struct __sul_process
> {
>   void *(*sul_malloc)(size_t size); /* May be called in USR or SVC mode */
>   void (*sul_free)(void *ptr);      /* May be called in USR or SVC mode */
>   __pid_t pid;
>   __pid_t ppid;
>   __mode_t umask;
>   void (*undef_handler)(void); /* Called by SUL (as the handler would normally
>                                   be called, not APCS) */

I don't understand this comment.  The environment handler in SUL will be
called.  Then that one will call the undef_handler routine.  But APCS-32
compliant ?

BTW, will struct __sul_process live in RMA or in the application space ?

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven



More information about the gcc mailing list