develooper Front page | perl.perl5.porters | Postings from August 2001

RE: [PATCH] Adding callbacks to the core

Thread Previous | Thread Next
From:
Arthur Bergman
Date:
August 22, 2001 10:42
Subject:
RE: [PATCH] Adding callbacks to the core
Message ID:
003501c12b32$e241b240$052aa8c0@foo
> On Wed, 22 Aug 2001, Robin Houston wrote:
> 
> > I'm definitely not an expert on this, but it definitely seems that if
> > you're _not_ an expert then this stuff is nearly impossible to get
> > right if you start trying to be clever.
> 
> You're probably right; I'm thinking about changing the 'disable_callback'
> docs to read this:
> 
>   Disable a previously registered callback.  If the callback is not
>   enabled, does nothing.  This may be called at any time in the
>   interpreter's main thread.
> 
> Then there is no problem since the callback will not go away unexpectedly
> unless the programmer is naughty, in which case they deserve what they
> get. :-)
> 
> - D

I do not know how many times I have to say this, the above code is faulty, if the next callback gets disabled.

I think there is a confusion of things.

We have two kinds of callbacks. Callbacks wich usually are on or off for a longer period of time. These will typically be like Devel::Cover. It would be nice to have lexically scoped callbacks. Requiring all the changes to these functions to be done from the current thread makes sense. In fact I do not understand why an external thread want to enable or disable callbacks, and I think this should be forbidden. It is the user of the perl code who adds or removes callbacks.

Then we have the second type of callback, which are one off events (kind of like signals). Potentially this could be done by pseudo signals. 

I think this should be optimized for the first kind. And thus we should optimize for dispatching not for adding or removing callbacks. I understand that we should be flexible, but a 45% overhead instead of a 6% overhead for calling an empty function is pretty wild. Note that even if every callback after it isn't that much slower, you still have the intial 45%.

I once again suggest an array which you just iter over calling every callback. And no mutex. If the callback needs some kind of data from another thread, I think the callback should take care of it's own protection. 

Or we go the other way and make every repeating function notify that it needs to be called and make everyone a oneoff event. The combination of these two seems to create a non optimal solution.

Arthur


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