develooper Front page | perl.perl5.porters | Postings from March 2014

Re: RFC: add discouragement warning to perl threads documentation

Thread Previous | Thread Next
Leon Timmermans
March 2, 2014 02:28
Re: RFC: add discouragement warning to perl threads documentation
Message ID:
On Sun, Mar 2, 2014 at 2:20 AM, Christian Walde

>  On Sun, 02 Mar 2014 02:01:36 +0100, Leon Timmermans <>
> wrote:
> I'm not quite sure what you mean with "threads can crash easily if shared
> data isn't meticulously flagged". On a C level, threads::shared shouldn't
> segfault [...]  If it does segfault, that is a bug that needs to be
> addressed.
> Note: By crash i am talking about any improper program termination, not
> just segfault, and also conflating data corruption into it for brevity.
> Keep in mind that that warning is meant to inspire fear, not to be
> technical reference material. ;)
> Specifically though i was thinking of a situation where an incompletely
> marked complex data structure is made available to two threads, resulting
> in them messing with it at the same time. If that can't happen, please
> correct me with suggestions on wording.

The current wording is extremely confusing to me. The current description
is pretty much "you can have bugs and that leads to crashes" to me.

(and in fact, it does use a global lock[1]).
> That's not a global lock, but a lock on shared variables. A global lock is
> when only one thread can execute at any one time. (See Python.) :)

The thing in Python is called a GIL: Global *Interpreter* Lock, which means
only one thread can be inside the interpreter (which doesn't quite mean
only one thread can execute at the same time, as long as all other threads
are doing IO or some such).

This is a lock on the shared interpreter (unlike python we have one per
thread plus the shared one, instead of one per process), that contains all
shared values, so only one thread can read or write to any shared value at
the same time. The lock is very much global in the sense that it's a lock
shared between all threads; as opposed to locks on individual shared values.

> Also, asynchronous libraries are only a useful replacement when using
> threads to multiplex IO, when you actually want to do multiprocessing the
> only alternative is forking (which obviously isn't helpful on Windows…)
> That is why it says "many situations", not "all situations".

IMHO, the multiprocessing case should be mentioned too, as it's actually a
far more valid use-case of threads (no really, one thread per IO channel
scales so poorly people shouldn't do it even if our threads had no overhead
over OS threads).


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About