[perl-win32-gui-hackers] Perl contexts [Was: Fixing Scintilla]

[Robert M. <rm...@po...>]

>> 2) I'm confused about the Perl context and how it's used within 
>> Win32-GUI - and how Scintilla should handle things.
>>
>> I've got it working by doing:
>>
>> dTHX;       /* fetch context */
>>
>> in the Scintilla event handlers, but had to remove NOTXSCALL/NOTXSPROC 
>> in some functions where the context isn't used/needed.
>>
>> If it would help, I can check in what I've got, with the idea of 
>> fixing things once I've got my head around these issues?
> 
> 
> I'm not overly familiar with this, but the concept is that a call to a C 
>  function that doesn't require perl context should look like a regular C 
> call;  A call from an XS sub (or anywhere that has a perl context 
> pointer available) to a function that requires a perl context should be 
> defined with a first argument of NOTXACALL/NOTXSPROC macro (but with no 
> following  comma).  These macros defined the correct type of argument to 
> pass the perl context.  I can do more investigation and expand on this 
> if necessary.

OK, I've just scanned the perldoc perlguts section entitled "How 
multiple interpreters and concurrency are supported".  I think it's 
reasonable to assume the following:

You can always define PERL_NO_GET_CONTEXT - all modern perl's will 
behave with this regardless of whether PERL_IMPLICIT_CONTEXT is defined 
or not (although it is defined for current ActiveState Perl builds - 
it's required for ithread support).  Defining pTHX, pTHX_, aTHX, aTHX_ 
and dTHX are dealt with in perl.h and XSUB.h

In Win32::GUI NOTXSPROC and NOTXSCALL are aliases for pTHX_ and aTHX_ 
respectively.  Any other code in GUI.h is purely for backwards 
compatibility with older perl's.  Even the "\n*** Using an implicit Perl 
context.\n" section should not be necessary, as pTHX_ and aTHX_ should 
deal with non-thread-capable perl builds.

To understand how to use pTHX_ and aTHX_ correctly read perlguts - but 
for consistency with Win32::GUI I would recommend using NOTXSPROC and 
NOTXSCALL macros in their place.

[ I've added a note to myself to look for all the places that we use 
dTHX and to ensure that they are necessary - I think they are used when 
we get a win32 api callback such that we can't use the NOTXSPROC calling 
convention ]

I hope this helps.

Rob.