Matt Fowles wrote:
I'm not very clear on the situation in Parrot with having multiple interpreters running in the same process. I know that Lua has this capability and that it's considered to be one of its major advantages over Python. If Parrot is being designed with this capability, then, presumably, more care needs to be taken with the ownership and locking semantics (if any) of tables like this.Dan~
On Mon, 9 Aug 2004 17:22:18 -0400, Dan Sugalski <[EMAIL PROTECTED]> 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
The secondary comment is that if Parrot has any leanings towards supporting Aspect-Oriented Programming (see recent versions of JBoss, for examples of some of the really nifty stuff you can do with this), it might be important to provide a mechanism for chaining function pointers in this table to allow custom handlers to be installed. Any thoughts on this one? To my mind, the question boils down to one of performance and one of security. The performance issue is I think, obvious. You want to be careful to keep these function calls lightweight unless you have a good reason for not doing so. The security one is more subtle - just that you need to be very careful what kind of code is able to install handlers. If code were able to install a blocking handler in "read()", for example, you could do some very nasty things.
However, the JBoss people have certainly found some very significant benefits to including AOP functionality. It also sounds like the kind of context-dependent behavior that Perl6 at least is being designed to support. Just something to think about, since I haven't heard any mentions of it anywhere else. Or perhaps it's an issue that should be discussed at a higher level?
Incidentally, these same questions also apply to at least the encoding API and possibly, the as-yet-unseen charset API.
