Article on Unixlib
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
BTW, will struct __sul_process live in RMA or in the application space ?
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc