Front page | perl.perl5.porters |
Postings from July 2001
On Thu, Jul 05, 2001 at 03:12:25PM +0200, Artur Bergman wrote: > 01-07-05 15.04, skrev David M. Lloyd på dmlloyd@tds.net följande: > > > On Tue, 3 Jul 2001, Benjamin Stuhl wrote: > > > >>> I have written an XS interface into a library that performs I/O and > >>> then can asynchronously call a C function upon completion. Is there a > >>> SAFE way I can reflect an asynchronous callback into Perl? > >> > >> AFAIK, only if the perl is built to expect such. In 5.8.0-to-be there > >> is the PERL_ASYNC_CHECK which is used for safe signals. You would have > >> to hack around a bit in the core to interface that to your XS, and > >> even then it would only work with a perl built for it. > >> > >> Maybe 5.8.0 should make PL_signal_pending or whatever it's called > >> public and provide a way for modules to register a event-checking > >> callback? > > > > I can't help but be jealous of PHP/Zend in this respect. I have a friend > > who just wrote a signal handling *add-on* module (that is, there was no > > hacking required of the core engine) because he was able to use an API > > function to insert a C callback that is called between every opcode (or > > whatever they call them... I think they have a subtly different name for > > the same concept). > > > > It would be awesome to have something like that in Perl. I guess that the > > performance hit associated with such a callback would be minimal... well > > worth the added power. > > > > - D > > > Like Benjamin said, we have PERL_ASYNC_CHECK that checks between opcodes, > this could added as a option to that. Or you could use a plugable runops function. Then you can do whatever you want without hacking the core. This sounds like just what you're after. > How hard would it be for PERL_ASYNC_CHECK to call a C callback instead of a > perl signal handler? And if that C callback did call_sv()... > > Artur -- Paul Johnson - paul@pjcj.net http://www.pjcj.netThread Previous | Thread Next