<div dir="ltr">Actually I just found this article: <a href="http://stackoverflow.com/questions/12166268/wheres-the-gil-in-pypy">http://stackoverflow.com/questions/12166268/wheres-the-gil-in-pypy</a> and it seems that the GIL is a feature specific to each interpreter. The link on that code lead me to module/thread/gil.py and that looks like it contains most of what I need. <br>
<br>Thanks!<br><br>Timothy</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 24, 2014 at 1:41 PM, Timothy Baldridge <span dir="ltr"><<a href="mailto:tbaldridge@gmail.com" target="_blank">tbaldridge@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 dir="ltr">What's the best way to tell rpython not to release the GIL during a given block of code? I haven't been able to find any code that describes when the GIL is acquired or when control could switch over to another thread. I'd prefer to have my interpreter bytecodes be atomic from the point of view from the program. If I had that, then I could easily build a psudo compare_and_swap by doing this:<br>

<br>dont_release_gil()<br>if foo.bar == oldval:<div>  foo.bar = newval</div><div>enable_gil_releasing()<br><br>Thanks,<br><br>Timothy<br><br><br></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">
On Sat, Feb 22, 2014 at 12:13 AM, Armin Rigo <span dir="ltr"><<a href="mailto:arigo@tunes.org" target="_blank">arigo@tunes.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Timothy,<br>
<br>
On 22 February 2014 01:39, Timothy Baldridge <<a href="mailto:tbaldridge@gmail.com" target="_blank">tbaldridge@gmail.com</a>> wrote:<br>
> compare_and_swap(foo.bar, oldval, newval)<br>
<br>
At some point we added a way to do it (basically you can do it<br>
yourself, by writing a one-line function in C and calling it).  We no<br>
longer do that: it's too much of a mess if you start having<br>
non-GIL-protected code written in RPython.  Either you are extremely,<br>
extremely careful, or random things will explode.  What we do instead,<br>
e.g. in the stm branches, is to write more C code.  For the complete<br>
parts that really need to run without any GIL protection, C is better<br>
than RPython after all.<br>
<br>
<br>
A bientôt,<br>
<br>
Armin.<br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><div class="">-- <br>“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”<br>
(Robert Firth) 
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”<br>(Robert Firth) 
</div>