develooper Front page | perl.perl6.language | Postings from June 2005

Re: Musing on registerable event handlers for some specific events

Thread Previous | Thread Next
From:
Adam Kennedy
Date:
June 9, 2005 00:04
Subject:
Re: Musing on registerable event handlers for some specific events
Message ID:
20050609015642.6487.qmail@lists.develooper.com
Gaal Yahas wrote:
> On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote:
> 
>>There will certainly be an event manager for all sorts of events floating
>>around in Perl 6.  The main trick will be to hide this from the people
>>who aren't interested.  The other trick will be to actually spec it,
>>since up till now I've assumed that it should be specced by the people
>>who are actually into that sort of thing.  Looks like you're one of
>>them.  :-)
> 
> 
> There's the touchy issue of what minimum compatibility level we're
> promising to deliver on all platforms. This is an issue in pugs already,
> where Windows GHC isn't compiled with POSIX libraries so we're stumped on
> the interface for even relatively basic things, such as how (or whether)
> File.open might offer O_EXCL.
> 
> Is part of the vision something like the explicit cross-platform nature
> of Java? Will I be able to write Perl6 code with a certain flag that
> possibly limits my choice of modules/builtins, but which promises me
> identical behavior on all supported platforms?
> 
> To take a notorious example, you mentioned fork() -- if this event manager
> becomes part of Perl6, does that mean we're required to emulate fork()
> on win32?

Your point is well taken. Hell, even I was debating generalising even 
further from "fork" to "preload". As in, having Perl emit an event which 
says "Hey everybody, now would be a _really_ good time to load 
everything in, because after we $whatever, it's going to be a lot more 
expensive to load them in at run-time that to just load them now and 
benefit from copy-on-write/threads/whatever."

Sort of a "disable run-time loading and load stuff now" event.

The reason I wanted a ten lines of code solution is so that the 
fork()-on-win32 issue is less of a problem.

If perl itself ONLY does (in p5 term)...

Some::EventManager->fire('prefork') if $INC{"Some/EventManager.pm"};

..then it would matter less whether or not fork ever happens on Win32.

The preload.pm module would simply register with Some::EventManager for 
a different set of events depending on which platform it is on. 
prefork.pm as it exists for P5 today doesn't _really_ care about fork(). 
What it _really_ wants to know is "Should I run-time load or not? Tell 
me when we need to stop run-time loading".

Some::EventManager might be part of the core, but it certainly wouldn't 
be loaded by default. It's just a normal module that gets loaded when 
someone needs to use it.

I'm a minimalist. I want something to does the absolute least amount of 
work needed to let me know about events I simply can't find out about 
any other way, and that perhaps we can add additional events to later.

I certainly DON'T want something big enough and heavy enough to be able 
to write Aspect.pm on top of.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About