Front page | perl.perl5.porters |
Postings from March 2014
On Sun, Mar 2, 2014 at 2:20 AM, Christian Walde <walde.christian@gmail.com>wrote: > On Sun, 02 Mar 2014 02:01:36 +0100, Leon Timmermans <fawaka@gmail.com> > 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). LeonThread Previous | Thread Next