[pypy-dev] Easy way to get access to cmpxchg?

[Maciej Fijalkowski]

yes, GIL is specific, but the PyPy GC is not really ready to do
multithreading. You would need a different (more thread aware) GC in
order to do that. Right now it assumes someone is holding some sort of
lock when allocating.

On Mon, Feb 24, 2014 at 9:47 PM, Timothy Baldridge <tbaldridge at gmail.com> wrote:
> Actually I just found this article:
> http://stackoverflow.com/questions/12166268/wheres-the-gil-in-pypy 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.
>
> Thanks!
>
> Timothy
>
>
> On Mon, Feb 24, 2014 at 1:41 PM, Timothy Baldridge <tbaldridge at gmail.com>
> wrote:
>>
>> 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:
>>
>> dont_release_gil()
>> if foo.bar == oldval:
>>   foo.bar = newval
>> enable_gil_releasing()
>>
>> Thanks,
>>
>> Timothy
>>
>>
>>
>>
>> On Sat, Feb 22, 2014 at 12:13 AM, Armin Rigo <arigo at tunes.org> wrote:
>>>
>>> Hi Timothy,
>>>
>>> On 22 February 2014 01:39, Timothy Baldridge <tbaldridge at gmail.com>
>>> wrote:
>>> > compare_and_swap(foo.bar, oldval, newval)
>>>
>>> At some point we added a way to do it (basically you can do it
>>> yourself, by writing a one-line function in C and calling it).  We no
>>> longer do that: it's too much of a mess if you start having
>>> non-GIL-protected code written in RPython.  Either you are extremely,
>>> extremely careful, or random things will explode.  What we do instead,
>>> e.g. in the stm branches, is to write more C code.  For the complete
>>> parts that really need to run without any GIL protection, C is better
>>> than RPython after all.
>>>
>>>
>>> A bientôt,
>>>
>>> Armin.
>>
>>
>>
>>
>> --
>> “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.”
>> (Robert Firth)
>
>
>
>
> --
> “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.”
> (Robert Firth)
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>