Re: [pypy-dev] GIL in non-Python languages
2011/3/7 Timothy Baldridge tbaldri...@gmail.com: I'm in the process of writing a PyPy based Clojure interpreter/JIT. One of the man tenants of Clojure is immutability, and one of the other tenants is extreme co-currency. Starting soon I'd like to start experimenting with co-currency in my interpreter. For those who aren't familiar with Clojure, let me give an example: (def my-agent (agent Hello)) (send my-agent #(str %1 World)) Send then takes the current state of my-agent and then calls the given lambda function, passing it the current state of the agent (%1 points to the first argument of the lambda). The lambda simply then concats the two strings together. So here's the deal. My entire interpreter is 100% thread safe. All my variables are either immutable, or local to the given function. But from what I'm hearing on IRC, it sounds like that a GIL will be automatically generated in my interpreter after I run it through PyPy. I know ripping the GIL out of Python is a major deal. But how about my project? If I start with the concept of a GIL-less interpreter, will PyPy get in my way? If so, how can I get it to back-off a bit? One major problem is that RPython its self is not really thread-safe. For example, the gc is very non-concurrent. So, that would have to be fixed. -- Regards, Benjamin ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] GIL in non-Python languages
Right, that would be an issue. In this case, I could probably start with a reference counting GCas I'm not exactly sure that it's possible to get cyclic references with immutable objects. At least not without allot of work...yeah, I'm pretty sure they are impossible to code in Clojure. But someone may correct me there. Anyway, reference counting would get rid of most of the parallel issues with the GC, I could simply use a CAS or atomic instructions to increment/decrement reference counts. Timothy One major problem is that RPython its self is not really thread-safe. For example, the gc is very non-concurrent. So, that would have to be fixed. -- Regards, Benjamin -- “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@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] GIL in non-Python languages
On Mon, Mar 7, 2011 at 9:08 AM, Timothy Baldridge tbaldri...@gmail.com wrote: Right, that would be an issue. In this case, I could probably start with a reference counting GCas I'm not exactly sure that it's possible to get cyclic references with immutable objects. At least not without allot of work...yeah, I'm pretty sure they are impossible to code in Clojure. But someone may correct me there. Hey. Refcounting GC would be generated for you, have you chosen to use it, but it'll be very inefficient and probably not thread safe. What you can do *right now* is to use boehm GC which is thread safe, but not very fast (much faster and much better than refcounting though). I don't think there are any other issues that are not thread safe in RPython than GC. Obviously it's like C - if you do something wrong you'll segfault. However, the true answer would be to work on a real GC that thread-friendly and thread-safe. This is work, it's however fun :-) Anyway, reference counting would get rid of most of the parallel issues with the GC, I could simply use a CAS or atomic instructions to increment/decrement reference counts. Timothy One major problem is that RPython its self is not really thread-safe. For example, the gc is very non-concurrent. So, that would have to be fixed. -- Regards, Benjamin -- “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@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
