Blocking ... is not blocking?

Sorry, but you're the one not making sense!

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.

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."