The simplest command line piping in a threaded build of bleadperl on VMS now gives the following errors:
$ perl -e "print 'ok';" | exit panic: free from wrong pool. panic: free from wrong pool during global destruction. %C-F-EBADF, bad file number I'm not sure where the bad file number comes from, but what's happening with the pool messages is that Perl_safesysfree in util.c has some new code that checks to see if we are deallocating memory from the same thread in which we allocated it (or, more properly, from within the same Perl interpreter context), and it yelps if not. On VMS, command-line piping is implemented by Perl itself, and such a pipe is opened at startup time before any thread context has been initialized. We are using Newx() to allocate memory for the structures used by our homegrown pipe implementation and Safefree() to deallocate them, but this gets us in trouble because for a command-line pipe we allocate before there is any thread context (my_perl == NULL) and deallocate after. Even if there is only ever one interpreter in the process, it looks like we are allocating and deallocating from different interpreters. There are some pipe structures that are clearly intended to be process-wide, shared by all pipes regardless of what thread they're in. I see no harm in simply using malloc() and free() for these and side-stepping the interpreter context issue. But there are other structures that are pipe-specific, and it seems like a good idea to keep the new sanity check that ensures we close a pipe and deallocate its structures from within the same interpreter context where it was opened. But I haven't thought of a good way to do that for the case where the pipe is opened when there is no context at all yet. Any suggestions? -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
