One general flow-of-control that I have used in similar situations is to equip the (C ...) DLL with a separate subroutine that the external context can call, in order to give it, ahead of time, the bit of information that the library will need to use later.   This bit of data must then be stored in thread-local storage by the DLL.   (The library’s initialization routine should explicitly set that slot to NULL.   Thus, if the slot is found to already contain a non-NULL value when this routine is called, an exception should be thrown.)

Before attempting to make the call, the DLL should verify that the slot contains a non-NULL value, and if it does, may assume that it contains the magic bit of data that is required.   (If not, the library should throw an exception.   The library should also be prepared to trap an exception occurring from the external call [to Perl ...], when that is attempted.)

For completeness, there should also be a second, “bye-bye, I’m going away now ...” entry-point in the DLL, whose sole purpose is to set that slot to NULL again, after doing any additional tear-down that may be required.   (If the slot is found to be NULL upon entry, this call is a no-op.)

Not Perl-specific, and “more than a bit of a hack,” but it works reliably.   (The suspicious, “throw an exception if anything smells funny” safeguards are a big part of that reliability.)