Plaz -- Some Requests

[AMadMonk]

First off, my CVS is giving me shitfits, so I'm doing dev work on a local private copy. I know this is doubleplus ungood, but for now I don't have an alternative. Maybe I can email you my sources and you can diff em into the repository?

Ok, I've decided to deal with the threading/reentrancy in Perl in exactly the same way you deal with it for the native macros -- I'll queue up events, and rely on the user to yield with a /doevents.

Perl will be tricky in that, unlike the native macroing, I can't control the rate of execution. So it's going to be like "#turbo" all the time.

The bounds of execution speed will be how fast MQ/EQ can process the IO commands (/echo, /sendkey, etc.) and what I do in the /doevents section.

Hmm, I just realized one more thing -- since all of the Perl IO calls will go through C code, including access to tied variables, I can bottleneck all of them through a single Sleep function with an adjustable timer. Hmm, that will work.

Okay, the rate of execution is no longer an issue. Heh.

The other thing is that since the perl interpreter has to run in its own thread, I need to serialize access to anything that modifies the state of EQ or the state of global variables (here's a good case for stuffing those globals into locals wherever possible!). Most of these can just have a simple critical section object associated with them. I'll have to be very careful to avoid deadlocks, but if we can keep the critsec code as small and tight as possible, that's not as huge of an issue. Lock discipline and just the simple expedient of avoiding grabbing locks inside critical sections of code will help.

Also, to make it as easy as possible to separate out the perl interpreter from the core of MQ, can we wrap functions that are NOT slash-commands in a declspec( dllexport ) too? That way we don't introduce MQ dependencies on the Perl module (which would stress me the hell out; I don't want my work to block other MQ dev work). We'll do it like the telnet server module, use a flag to indicate whether or not perl is loaded, and if not, we'll skip those bits of code. This should also let me distribute my perl interpreter mod as a separate dll that you can dynamically load or unload.

Anyway, rambling. Two key requests: wrap the risky runctions (that perl would be interested in calling) in critical sections, and extern "C" __declspec ( dllexport ) them.

Ok, back to work.