Threads are unsafe, period.<div><br></div><div>Personally, I think the threading packages should be removed from Python entirely.</div><div><br></div><div>The GIL makes them pseudo-pointless in CPython anyway and the headaches arising from</div>

<div>threading are very frustrating.</div><div><br></div><div>Personally I would rather see an Actors library...<br><br><div class="gmail_quote">On 4 November 2011 04:30, Jim Jewett <span dir="ltr"><<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Nov 2, 2011 at 3:36 PM, Mike Meyer <<a href="mailto:mwm@mired.org">mwm@mired.org</a>> wrote:<br>


<br>
</div><div class="im">> 1) How much of the Python standard library is known to be thread safe?<br>
<br>
</div>None.  Though our confidence in the threading library is fairly high<br>
(except when the underlying C library is broken).<br>
<br>
Not so long ago, there were a series of changes to the regression<br>
tests that boiled down getting rid of spurious failures caused by<br>
tests running serially, but in an unusual order.  If that level of<br>
separation was still new, then finer-grained parallelism can't really<br>
be expected to work either.<br>
<br>
That said, test cases relied far more on global state than a typical<br>
module itself does, so problems are far more likely to occur in user<br>
code than in the library.<br>
<div class="im"><br>
<br>
>  a) I proposed making actions that mutate data require locked objects,<br>
> because I've seen that work in other languages. I recognize that<br>
> doesn't mean it will work in Python, but it's more than I can say<br>
> about the alternatives I knew about then.,<br>
<br>
</div>If you really want to do this, you should probably make the changes at<br>
the level of "object" (or "type") and inherit them everywhere.  And it<br>
may simplify things to also change the memory allocation.<br>
<br>
There are a few projects for remote objects that already use a<br>
different memory model to enforce locking; you could start there.<br>
<div class="im"><br>
>  b) Bertrand Meyer's SCOOPS system, designed for Eiffel. It has two<br>
> major strikes against it: 1) it is based on type attributes on<br>
> *variables*, andI could figure out how to translate that to a language<br>
> where variables aren't typed.<br>
<br>
</div>Actually, that isn't so bad.  Common Lisp doesn't normally type<br>
variables at the source code level, but<br>
    (a)  You can explicitly add typing information if you want to, and<br>
    (b)  The compiler can often infer types<br>
<br>
If you want this to mesh with python, the constraints are similar; not<br>
only does the locking and safety marking have to be unobtrusive, it<br>
probably has to be optional.  And there is existing (if largely<br>
superseded by Pypy) work on type inference for variables.<br>
<span class="HOEnZb"><font color="#888888"><br>
-jJ<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br></div>