in reply to Re^3: Pursuading an XS module to use a routine from another XS module.
in thread Pursuading an XS module to use a routine from another XS module.
Note that, with this approach, you'll probably be making significant alterations to both source distros.
That's the problem, it shouldn't not be necessary to c&p code from both modules, into a third, to do this. It makes a mockery of having libraries. And if I link the MT code directly from the List::Util code, I'm effectively including the MT code directly into the List::Util package.
As the anonymonk suggests, it is perfectly possible to call the Perl front end for an XS module in another package using call_pv( "Math::Random::MT::rand" );. But that means going through both the Perl and XS wrappers to get from C to C.
Introducing both overhead (which is what we're trying to avoid by using XS), and complexity: wrapping C arguments into Perl values (SVs) in order to pass them into the routine we're calling and then unwrapping the Perl responses back to C values. On top of that you need to add an extra Perl level block scope to protect your layer from the possibilities of the routine you're calling messing with the Perl stack. And if you get the stack handling wrong, it's a nightmare to debug.
The routines I need to call in MT.xs are (become) straight C functions that live in MT.dll:
Math::Random::MT mt_setup(seed) U32 seed CODE: RETVAL = mt_setup(seed); OUTPUT: RETVAL double mt_genrand(self) Math::Random::MT self CODE: RETVAL = mt_genrand(self); OUTPUT: RETVAL
In normal C code, calling a routine from within a DLL is just a case of calling LoadModule() followed by GetProcAddress() (or the platform equivalents) and you're good to go. But XS dlls do not export the addresses of the routines they contain directly. Instead, they export a boot_MODULENAME entrypoint and Dynaloader::bootstrap takes care of calling that entrypoint to obtain the list of "exported" subroutines and installs them (in the current package? Current to where? The calling perl code or the calling XS code?).
But understanding that process and replicating it from within XS code is another nightmare.
The right way to do what I want to do, would be to:
In theory, those are 3 fairly simple steps. In practice, I haven't a clue how to go about the first two. Or where to go to get assistance. As in the past, XS questions at this level get precious little if any responses (except from your own good self) :(
There is already a module out there that provides a MT-based shuffle: Math::Random::MT::Auto. It goes the route of incorporating it's own implementation of the Mersenne Twister PRNG. However, it comes with a bunch of other stuff I have no need or desire for and is much slower than List::Util and Math::Random::MT. I also have some doubts about the implementation of the MT that I don't have with the M::R::MT version. And it's a fundamentally bad thing to have two independant PRNGs in use at the same time.
As always when I start trying to mess with XS. I know what I want to do, I just lack the knowledge of how to achieve it, or how to get expert assistance in trying to achieve it. What we need is an XSMonks site, but if we threw the party, do you think anyone would turn up?
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^5: Pursuading an XS module to use a routine from another XS module.
by syphilis (Archbishop) on Sep 03, 2008 at 12:06 UTC | |
by BrowserUk (Patriarch) on Sep 03, 2008 at 12:32 UTC | |
by syphilis (Archbishop) on Sep 03, 2008 at 12:55 UTC |