Monday, April 05, 2010

A challenge for a XS hacker

Recently we at Best Practical was discussing penalties of callbacks in RT. Callbacks are proved to be very good way to extend the web UI. We call a function from component, function checks for registered customizations for this particular place and calls them, so custom code can either change arguments or inject something into result stream.

Number of places where callbacks are called gets bigger and bigger. And an idea came to me. What if we can say to the caller to stop calling us. I believe it's possible to do.

For example a function gets called and at some point we understand that all the time for a live of the process we are going to escape or return the same value. In this case we call function that finds caller's optree and rebuilds it by injecting a constant. So it's runtime consting of function's result in a particular place.

I hope that experienced XS hackers may be interested, as there are plenty of users of this on the CPAN. Class::Trigger comes to mind.

Anyone?

3 comments:

  1. Anonymous12:20

    Hi Ruslan,

    have a look at what chocolateboy did to Class::XSAccessor considering run-time rewriting of the op tree. XSAccessor.xs has some fairly extensive documentation at the top.

    Do note, however, that rewriting the optree isn't really thread-safe. We have never seen any problems with it, but in principle, it could lead to all sorts of crashes.

    Cheers,
    Steffen

    ReplyDelete
  2. Anonymous12:22

    Oh drat, I forgot to mention that for Class::XSAccessor, I already implemented all sorts of threading-related locking for the access to global data structures. That should be extensible to the optree munging.

    ReplyDelete
  3. Steffen, thanks for comments. Changing pp_addr is a good start. Probably there plenty of space to improve.

    ReplyDelete