Tim Pushor <[EMAIL PROTECTED]> writes: >> >> i humbly suggest that either redesigning the C interface or designing >> a new and sane perl interface around it would be a better approach. >> at the very least, having each operation in C code take a pointer to a >> structure containing execution context (the double and any other state >> information (think of a C++ object)) would give you a cleaner API with >> free reentrancy. >> >You are right, that was not a very good way of going about it. I felt >that from the start, but this code is ISAM database code, and the >variable in question is the block pointer. This pointer gets updated >every time an ISAM operation is done - which is at least once for each >record scanned/loaded. I wanted to avoid copying variables back and >forth on each ISAM operation, for more efficiency.
The "Subject:" vesion can be done, but is a bit messy. The problem is making sure the lifetime of the shared thing is long enough fro both C and perl. What Tk does for a few "global" C vars like this is declare & define them as C. Then create perl proxies for them with XS code to provide FETCH and STORE of a 'tie'. So when perl goes for $foo it calls Module::FETCH which is XS code which grabs the C variable and puts in in a perl SV and returns it. Or Module::STORE which gets value from perl and writes it to the C variable. This scheme is more robust than having C code use SvNV slot of some perl SV. The latter can be done, but SV probably needs is SvREFCNT incrementing to make sure it stays about. Main snag with that and double (in particular) is that say: $var = 3; _May_ not set NV at all, but the IV slot. And $var = '3'; is even worse. The 'tie' scheme give your XS code a hook to force conversion to C's type. However collecting things in to an "execution context" as suggested is likely to be cleaner. > >I don't know enough to do it, but I did make it work with a scalar >reference. A clean scheme is put a C "struct" in the string slot of an SV. If this is just opaque data that is all you need to do, and perls REFCNT will free string at right time. To get at sub-fields from perl side with provide XS "methods" as accessors or (if struct isn't too complex) accessors in perl code that use pack/unpack on the data. >Unfortunately I had to do what I set out not too, but at this >point - I'm just glad it seems to work ;-) This can be complicated. > >Thanks, >Tim > >>
