Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^11: threads on Windows

by ikegami (Patriarch)
on Feb 22, 2009 at 06:49 UTC ( [id://745599]=note: print w/replies, xml ) Need Help??


in reply to Re^10: threads on Windows
in thread threads on Windows

You said <> isn't blocking thread creation, and proceed to contradict yourself as you said <> uses a mutex and "the cloning of the current thread will be blocked until that mutex is released".

Are you implying that we should have said

<> obtains a lock on STDIN, one which is also required to clone STDIN, an activity that occurs when a new thread is created, thus preventing new threads from being created until the read is complete.

instead of

<> blocks thread creation

If so, that would be ironic given the content of your home node.

Replies are listed 'Best First'.
Re^12: threads on Windows
by BrowserUk (Patriarch) on Feb 22, 2009 at 07:51 UTC
    Are you implying that we should have said

    No. Because that would be equally naive, and incorrect. (And this is anything but pedantry.)

    • It's not <> (nor readline nor getc nor recv nor...).

      It's any blocking operation on a shared resource.

    • And that operation doesn't "obtain a lock", it enters a mutex.

      And it cannot leave the mutex until it completes. Any other operation that tries to enter that mutex will be blocked pending that completion.

    • The "other operation" in this case is CLONE, not thread creation.

      Whilst cloning is (unfortunately) an integral part of an iThread spawn, thread creation is not the only time cloning can occur.

    So, whilst: "<> [on a filehandle connected to a terminal] blocks thread creation [if that filehandle needs to be cloned for that thread creation to go ahead]", is a logical consequence of "operations on PGRs being serialised by perl"; it isn't a bug, nor limitation, nor caveat--it is a requirement--implemented correctly and WAD.


    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.

      It's any blocking operation on a shared resource.

      WTF? Even if it's not the only thing that blocks thread creation doesn't mean preclude it from being one of the things that blocks thread creation.

      And that operation doesn't "obtain a lock", it enters a mutex.

      WTF? You of all people should know they're the same thing. "A mutex is also a common name for a program object that negotiates mutual exclusion among threads, also called a lock."

      The "other operation" in this case is CLONE, not thread creation.

      WTF? The clone is part of the thread creation. So if the clone blocks, thread creation blocks too.

      it isn't a bug, nor limitation, nor caveat--it is a requirement--implemented correctly and WAD.

      I agree that it's not a bug, but you're wrong on the other two.

      It's definitely a limitation. The OP's code didn't work.

      The behaviour of a program can never be caveat any more than it can be blue, so that's a weird thing to list.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://745599]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (8)
As of 2024-04-19 09:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found