Re: Musing on registerable event handlers for some specific events
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.
Re: Musing on registerable event handlers for some specific events
: If it can be done in less than 10 lines lines of code, to get the most : minimal hooks into the core, I'd like to see it done. 10 lines? I laugh in your general direction. No really. In perl itself, I just to see... throw Event(CORE::prefork) if $Event::Manager::VERSION; ...or something equally simple. Fair enough Event::Manager itself might be a little larger... but even then it shouldn't need to be more than a couple of dozen lines. prefork.pm is currently about 30-40, and you should only need the hashified version of it.
Re: Musing on registerable event handlers for some specific events
On Wed, 8 Jun 2005 18:57:30 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: On Wed, Jun 08, 2005 at 11:04:30PM +0300, Gaal Yahas wrote: : On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote: : 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? Perl 5 manages it, and Perl 6 is expected to emulate Perl 5 when fed Perl 5 code. It's one of the reasons Parrot is aiming to support an ithreads model in some fashion or other, I expect. But it's okay if the Pugs interpreter punts on this for now. If the only reason for using the ithreads model is to allow fork() to be emulated using the same mechanism as is used in P5 -- please don't. The reason for supporting fork() is (mostly) to allow unix fork() exec() idioms to operate on Win32, but mostly they don't anyway because Win32 doesn't support the other components required (signals SIG_CHLD etc.; COW) required to allow those idioms run transparently. The p5 fork() emulation is barely usable, and has so many caveats that there will never be the possibility of transparent portability of programs that use fork() to Win32. It will always be necessary to test for platform and make special provisions. And the only instances where the fork emulation does work reasonably well are those that are doing fork() exec(). But thin about that. The emulation, spawns a thread, duplicates all the code and all the data from the main thread and then...Starts a new process. All that copied code and data is never used because all the spawned thread does is sit and wait for the new process to die. Other uses of fork() like alarm(), also don't work in Win32. Cygwin manages to perform a proper fork(). The code isn't even that complicated. Larry
Re: Musing on registerable event handlers for some specific events
Nigel Sandever wrote: On Wed, 8 Jun 2005 18:57:30 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: On Wed, Jun 08, 2005 at 11:04:30PM +0300, Gaal Yahas wrote: : On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote: : 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? Perl 5 manages it, and Perl 6 is expected to emulate Perl 5 when fed Perl 5 code. It's one of the reasons Parrot is aiming to support an ithreads model in some fashion or other, I expect. But it's okay if the Pugs interpreter punts on this for now. If the only reason for using the ithreads model is to allow fork() to be emulated using the same mechanism as is used in P5 -- please don't. I'll second that. While each version of p5 makes progress towards fork() on Win32 being moderately useful, I still find that only reliable way to do automated multi-processing is to whip out Win32::Process and start a new interpreter with special I'm a child process arguments. -- Rod Adams
Re: Musing on registerable event handlers for some specific events
On Wed, Jun 08, 2005 at 03:57:14PM +1000, Adam Kennedy wrote: : What I'd like to see for Perl 6 (and I'm not sure if this exists : already), is some sort of minimal event manager. 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. :-) : The number of events I'm talking about would be extremely low, pre and : post fork being one. I'm not sure about others, but again I'm imagining : only events that matter process-wide. : : I'd like to see the Perl 6 fork() command issue event triggers to some : officially blessed event manager module. Any number of other modules : could register callbacks for whichever events they liked. It seems to me that the tricky bit is knowing when everyone has finished doing everything they want to do before you actually fork. Just because you fire off someone's event handler doesn't mean that half the things they're going to want to do based on that aren't also asynchronous... : The other alternative is to have the event manager overwrite the core : fork() function... and I dislike this sort of hackery as these tricks : generally only work if one person does it. Me too. : If it can be done in less than 10 lines lines of code, to get the most : minimal hooks into the core, I'd like to see it done. 10 lines? I laugh in your general direction. Larry
Re: Musing on registerable event handlers for some specific events
Adam Kennedy skribis 2005-06-08 15:57 (+1000): The number of events I'm talking about would be extremely low, pre and post fork being one. I think they're much more useful being two. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Musing on registerable event handlers for some specific events
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? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Musing on registerable event handlers for some specific events
With my occasionally-stated preference for keeping the Perl 6 core slimmer than it already is, I feel a little silly about suggesting new features for P6, but I'd like to stimulate debate on one that I'd like to see. Last year I was having some issues with a large web application that needed to run as both a CGI and mod_perl application. In particular, I wanted an effect where modules that I didn't need for every call weren't loaded unless appropriate. Now for CGI that means run-time loading. We have a number of these, from AutoLoader to (my) Class::Autouse module. In mod_perl or other forking scenarios these same modules should be preloaded BEFORE the fork, so that they only use memory once, not many times. Although Class::Autouse already magically supported mod_perl and preloaded, it was obvious that this was the wrong approach. There needed to be a way to preload for ALL forking scenarios without duplicating logic all over the place. As a result, I ended up creating prefork.pm to allow different modules to register callbacks that would be triggered just before forking, so that various run-time loading hooks could all be triggered and loaded automatically before the fork. This has worked for me quite well, but is a voluntary situation in which any forking module has to trigger the prefork logic manually. What I'd like to see for Perl 6 (and I'm not sure if this exists already), is some sort of minimal event manager. The number of events I'm talking about would be extremely low, pre and post fork being one. I'm not sure about others, but again I'm imagining only events that matter process-wide. I'd like to see the Perl 6 fork() command issue event triggers to some officially blessed event manager module. Any number of other modules could register callbacks for whichever events they liked. The other alternative is to have the event manager overwrite the core fork() function... and I dislike this sort of hackery as these tricks generally only work if one person does it. If it can be done in less than 10 lines lines of code, to get the most minimal hooks into the core, I'd like to see it done. Thoughts? Adam K
Re: Musing on registerable event handlers for some specific events
On Wed, Jun 08, 2005 at 11:04:30PM +0300, 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. Pugs might require a Parrot back end to support this. But let's remember that we're viewing Pugs primarily as a bootstrap and reference compiler, not necessarily a production compiler/interpreter. The production compiler will be in Perl 6, and the production VM will have a Parrot interface, even if it's not Parrots all the way down. : Is part of the vision something like the explicit cross-platform nature : of Java? It would be nice to do that as good as or better than Java does, except when we want to do it worse on purpose. : 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? It's possible to set up such a flag, but I don't know how useful it'll be. In the coming age of parallelism it is going to be close to impossible for any machine (virtual or real) to make any such promise. We are designing several kinds of parallelism right into Perl 6 to take advantage of the new hardware. Algorithms that rely on reproducible ordering where none is guaranteed will be considered vaguely erroneous. : 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? Perl 5 manages it, and Perl 6 is expected to emulate Perl 5 when fed Perl 5 code. It's one of the reasons Parrot is aiming to support an ithreads model in some fashion or other, I expect. But it's okay if the Pugs interpreter punts on this for now. Larry
