What do you mean by CRT?

CRT == C RunTime libraries.

Presumably all the versions of perl you tested were built using GCC and its runtime libraries? If those libraries have a bug they could be affecting all the versions you've tried.

Another, and possibly more likely candidate is that the PERLIO implementation for unix/POSIX platforms has a bug that doesn't manifest itself in the MSWIN branches of the source tree.

Two things that you could try--if you have the inclination to try and track this down:

1. Re-build your local perl setting USE_PERLIO = undef or whatever the equivalent configuration parameter is for your system(s).
2. See if you can get someone who runs perl under cygwin (and/or Strawberry Perl) to see if they can reproduce the problems you are having.

Beyond that, report the problem to the threads maintainer and see what if any reaction you get.

2. See if you can get someone who runs perl under cygwin (and/or Strawberry Perl) to see if they can reproduce the problems you are having.

Does not work too in cygwin

$ perl -v
This is perl, v5.10.0 built for cygwin-thread-multi-64int

$ perl -Mthreads -e  'print $threads::VERSION'
1.69

$ perl -Mthreads::shared -e  'print $threads::shared::VERSION'
1.21
[download]

I'm replying here cos it's too much to do via /msg

gulden says We can clone filehandles, but can u ensure tha they share buffers, locks and son on?

On (native) Win32 & Win64 I'll give you a qualified yes. On the evidence of your posts, maybe not on other (POSIX) platforms.

To the best ability to track this through, the difference lies somewhere below this function in sv.c:

PerlIO *
PerlIO_fdupopen(pTHX_ PerlIO *f, CLONE_PARAMS *param, int flags)
{
#if defined(PERL_MICRO) || defined(__SYMBIAN32__)
    return NULL;
#else
#ifdef PERL_IMPLICIT_SYS
    return PerlSIO_fdupopen(f);
#else
#ifdef WIN32
    return win32_fdupopen(f);
#else
    if (f) {
    const int fd = PerlLIO_dup(PerlIO_fileno(f));
    if (fd >= 0) {
        char mode[8];
#ifdef DJGPP
        const int omode = djgpp_get_stream_mode(f);
#else
        const int omode = fcntl(fd, F_GETFL);
#endif
        PerlIO_intmode2str(omode,mode,NULL);
        /* the r+ is a hack */
        return PerlIO_fdopen(fd, mode);
    }
    return NULL;
    }
    else {
    SETERRNO(EBADF, SS_IVCHAN);
    }
#endif
    return NULL;
#endif
#endif
}
[download]

With the Win* versions complying with this description from the POSIX standard:

     The object referenced by the descriptor does not distinguish betw
+een
     fildes and fildes2 in any way.  Thus if fildes2 and fildes are du
+plicate
     references to an open file, read(2), write(2) and lseek(2) calls 
+all move
     a single pointer into the file, and append mode, non-blocking I/O
+ and
     asynchronous I/O options are shared between the references.  If a
+ sepa-
     rate pointer into the file is desired, a different object referen
+ce to
     the file must be obtained by issuing an additional open(2) call. 
+ The
     close-on-exec flag on the new file descriptor is unset.
[download]

other (ironically POSIX) platforms not!

I'm guessing (on the basis of little more than gut feel and my abortive attempts to trace this through perlio.c, that the problem lies with the perlio implementation of the dup2 semantics rather than the underlying OSs (which would have noticed this much earlier).

If you compile your own Perl on one of those platforms, then you could try using stdio instead of perlio and confirm or not my suspicions. Alternatively, put together a simple testcase that demonstrates the problem (or use mine from above that works for me and fails for you), and raise a PerlBug.

As for locking: you don;t need to be able to share the filehandle in order to use locking. You declare a simple shared scalar and perform your locking on that.

Sorry that I cannot explain this better, nor help you with non-Win* platforms.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW

Again, it looks like a genuine bug in POSIX builds of Perl or the underlying libraries.

As I don't run any of the systems where the failure occurs, I cannot help you further. There is really nothing you can do about it other than report it to the package mainatainer and/or p5p (via perlbug).

You might be able to work around the bug by:

1. Passing the fileno of the open file handle to each thread explicitly;
2. Use POSIXdup() to clone the file descriptor manually;
3. Use POSIXwrite() to write to it.

In theory, you can use 'dupping' syntax of open (open my $fh, '>&', $fno) to achieve this, but chances are that is essentially what is being done when an open filehandle is automatically cloned, and so it would likely suffer the same problems if you do it yourself.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."