Functions for embedders to override
Dan Sugalski
run into Apache issues as well as any number of other systems....
When Parrot's being embedded I can see the following functions
needing overriding by the embedder:
*) Memory: malloc, realloc, calloc, free
*) Signals: handler register, Handler un-register, signal raise, alarm set
*) Files: Open, close, seek, tell, read, write. (Possibly asynchronously)
I want to get these defined and a system in place to allow overriding
functions to be registered to give embedders control over parrot's
interface to the 'real world', and so we can get the source fixed up
now, rather than put it off even more.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
>Since we're running into Ponie issues with this, which means we'll
>run into Apache issues as well as any number of other systems....
>
>When Parrot's being embedded I can see the following functions
>needing overriding by the embedder:
>
>*) Memory: malloc, realloc, calloc, free
>*) Signals: handler register, Handler un-register, signal raise, alarm set
>*) Files: Open, close, seek, tell, read, write. (Possibly asynchronously)
And we want to add exiting to that list. Which presents some
interesting issues we need to think about, since we probably need to
throw an exit exception instead.
Matt Fowles
On Mon, 9 Aug 2004 17:22:18 -0400, Dan Sugalski <d...@sidhe.org> wrote:
> At 12:04 PM -0400 8/9/04, Dan Sugalski wrote:
> >Since we're running into Ponie issues with this, which means we'll
> >run into Apache issues as well as any number of other systems....
> >
> >When Parrot's being embedded I can see the following functions
> >needing overriding by the embedder:
> >
> >*) Memory: malloc, realloc, calloc, free
> >*) Signals: handler register, Handler un-register, signal raise, alarm set
> >*) Files: Open, close, seek, tell, read, write. (Possibly asynchronously)
>
> And we want to add exiting to that list. Which presents some
> interesting issues we need to think about, since we probably need to
> throw an exit exception instead.
>
Would having a table of function pointers for these various functions
be an appropriate solution, or does that have issues that I am not
seeing? We could then initialize them ourselves at startup (even
using different allocaters based on commandline switches) and then
provide routines to set these later (if someone wanted to do it that
way).
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
Dan Sugalski
A global table of functions is an excellent way to go about this, and
what we should do ourselves internally. Having a:
Parrot_Override_Function(INTVAL funcnum, (wacky function pointer
cast)funcptr)
entry in the embedding API wouldn't be out of order either, I think.
Benjamin K. Stuhl
> Since we're running into Ponie issues with this, which means we'll run
> into Apache issues as well as any number of other systems....
>
> When Parrot's being embedded I can see the following functions needing
> overriding by the embedder:
>
> *) Memory: malloc, realloc, calloc, free
> *) Signals: handler register, Handler un-register, signal raise, alarm set
> *) Files: Open, close, seek, tell, read, write. (Possibly asynchronously)
*) Environment: getenv, setenv
*) Threading/Process manipulation? (fork, spawn, wait, pthread_*) (Consider
an application built on a runtime that expects to know about all threads
in a process, or an embedder who wants to let their Parrot programs call
back into the main program or integrate into their main event loop.)
* Networking: socket, accept, connect, listen, etc. (see "Files")
A good place to look at for the complete list is Perl 5's system abstraction
layer.
-- BKS