in reply to Re^2: [threads] Open a file in one thread and allow others to write to it
in thread [threads] Open a file in one thread and allow others to write to it

S'funny, cos the code I posted is very well tested (going back to 5.8.0 and right upto 5.8.9 & 5.10.1 (64-bit)!

The mistake you're making is reading "Filehandles cannot be made 'shared'." to mean 'filehandles cannot be shared'. Those phrases do not be not mean the same thing.

Filehandles are process global entities and therefore can be cloned. Which means that each thread created after a filehandle comes into existance gets it's own copy of the global.

Try the code I posted. Tell me how you get on :)

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 It is as I've been saying!(Audio until 20090817)
  • Comment on Re^3: [threads] Open a file in one thread and allow others to write to it

Replies are listed 'Best First'.
Re^4: [threads] Open a file in one thread and allow others to write to it
by gulden (Monk) on Nov 16, 2009 at 13:14 UTC
    This is our endless discussion. «Filehandles cannot be made 'shared'», maybe in your OS it works, not in the OS's i've tested. When you clone the Filehandle you are assuming that OS will sync the File->writes without any race conditions problems, but that is not true.

    Updated:

    This is what happens when removing the sleep()'s:

     1: The time is 1258377733.481062
 1: The time is 1258377733.481164
 1: The time is 1258377733.481337
 1: The time is 1258377733.4 3: The time is 1258377733.473267
 3: The time is 1258377733.473595
 3: The time is 1258377733.473749
 3: The time is 1258377733.473885
 3: The time is 1258377733.474008
 3: The time is 1258377733.474110
 3: The time is 1258377733.474212
 3: The time is 1258377733.474313

    [download]

    In high concurrency level, the problems appear.

    «A contentious debate is always associated with a lack of valid arguments.»
[reply]
[d/l]
      you are assuming that OS will sync the File->writes without any race conditions problems,

      Um. No. That's why I used a shared variable to coordinate 

      my $sem :shared;
open LOG, '>', 'log.txt' or die $!;


sub logit {
    lock $sem;
    return printf LOG @_;
}

      [download]

      Perhaps you could just try running the code I posted where you are, and tell me what problems you see?

      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.
[reply]
[d/l]

        «That's why I used a shared variable to coordinate »

        Your lock variable coordinates the concurrency between Perl Threads, it won't sync the OS File->writes, cos each Thread is using a cloned FileHandled and you are trusting OS Synchronization.

        Now I make you a question? Why are you using a lock variable, since you are using a cloned FileHandle that is not shared between threads? You are trusting the OS sync, so the use of that shared LOCK variable is useless.It only minimizes OS->File->Writes thread concurrency

        «A contentious debate is always associated with a lack of valid arguments.»
[reply]
          A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom