lily has asked for the wisdom of the Perl Monks concerning the following question:

Hello,

I'm using perl58.dll (version 5.8.4, build 810) in a c++ application with several threads that runs on win2000SP4. Every thread creates a perl interpreter that runs a perl script from an arbitrary file. After a while I'm experiencing a deadlock. I can see that I have a thread that is stack in the function _alloc_osfhnd (Microsoft function from the msvcrt.dll that is called from the _open function).

I found this link http://bugs.mysql.com/bug.php?id=12071 that describes a Microsoft bug in _alloc_osfhnd that might cause this deadlock.

I can also see that in the perl source win32.c there's an implementation to the function _alloc_osfhnd with the following description, but I'm not sure it has something to do with my problem.

/* * we fake up some parts of the CRT that aren't exported by MSVCRT.dll + * this lets sockets work on Win9X with GCC and should fix the problem +s * with perl95.exe * -- BKS, 1-23-2000 */
Has anyone experienced this problem before?
Is it really a Microsoft bug that affects perl?
Can another version of perl solve the problem?
Can another version of OS solve the problem?

I attached my relevant code below,
Thanks in advance,
Lily.

__declspec(dllexport) long CFTPerlUserExitInstanceRun(char *FileName,char *FuncName,struct P +erlParmInfo *ParmsVec,unsigned int ParmsVecSize,char* pReason,int *pC +ount,int *pUserExitRc, int *pPerlParseRc) { long lRc = 0; int count = -1; PerlInterpreter* my_perl = NULL; char *embedding[] = { "", FileName}; while (true) { my_perl = perl_alloc(); if (my_perl == NULL) { lRc = -1; break; } EnterCriticalSection(&g_ParserCS); try { PERL_SET_CONTEXT(my_perl); PL_perl_destruct_level = 1; perl_construct(my_perl); *pPerlParseRc = perl_parse(my_perl, xs_init, 2, embedding , N +ULL); lRc = *pPerlParseRc; LeaveCriticalSection(&g_ParserCS); } catch(...) { LeaveCriticalSection(&g_ParserCS); lRc = -6; break; } if (lRc != 0) { lRc = -2; break; } dSP; ENTER; SAVETMPS; PUSHMARK(SP); // Here I push parameters into the stack… PUTBACK; try { count = call_pv(FuncName, _EVAL|G_SCALAR); } catch(...) { lRc = -3; } SPAGAIN; // Check the eval first if (SvTRUE(ERRSV)) { STRLEN n_a; strncpy(pReason, SvPV(ERRSV, n_a), MAX_PERL_REASON_LENGTH-1); lRc = -4; POPs ; } else { if (count != 1) { *pCount = count; lRc = -5; } else { *pUserExitRc = POPi; } } PUTBACK ; FREETMPS ; LEAVE ; break; } if (my_perl != NULL) { EnterCriticalSection(&g_ParserCS); try { PL_perl_destruct_level = 1; perl_destruct(my_perl); LeaveCriticalSection(&g_ParserCS); } catch(...) { LeaveCriticalSection(&g_ParserCS); lRc = -7; } perl_free(my_perl); } return lRc; }

Replies are listed 'Best First'.
Re: perl on windows - possible bug?
by jdtoronto (Prior) on Sep 18, 2006 at 00:31 UTC
    I know you ask if another version might influence the proboem, yes, but have you tried it? Build 5.8.4 810 is over 2 years old. The latest release is 5.8.8 819.

    As for Microsoft bugs, yes, although I haven't run into one recently I have certaily seem them in the past.

    jdtoronto

Re: perl on windows - possible bug?
by Anonymous Monk on Sep 18, 2006 at 03:01 UTC
    Instead of _EVAL, don't you want G_EVAL?
      Yes, it is G_EVAL. It was somehow deleted when i copied the code...