Re^11: 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.

Comment on Re^11: threads on Windows Select or Download Code

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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]
Re^13: threads on Windows by ikegami (Patriarch) on Feb 22, 2009 at 08:11 UTC
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.	[reply]
Re^14: threads on Windows by BrowserUk (Patriarch) on Feb 22, 2009 at 08:21 UTC
WTF? ... Drinking alcohol is often a part of seduction, but you don't blame alcoholism on procreation. 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."	[reply]
Re^15: threads on Windows by ikegami (Patriarch) on Feb 22, 2009 at 08:28 UTC