Carl Witty, 08.08.2010 22:11: > On Sun, Aug 8, 2010 at 2:15 AM, Stefan Behnel wrote: >> Remember that the GIL makes your life easier. Cython is about writing >> extension modules, and very, very many of those only work *because* of the >> GIL. Here's an example: >> >> http://code.activestate.com/recipes/577336-fast-re-entrant-optimistic-lock-implemented-in-cyt/ >> >> In the Cython wrappers I wrote so far, a *lot* of critical code truly >> relies on the GIL. >> >> So, one part of porting Cython to .NET would be to add a global lock for >> the code (at least when threading is used, which may be tricky to >> determine). Obviously, this could become a compiler option for the .NET >> backend, but the lock would still have to be turned off explicitly in order >> to prevent breaking Cython code by default. > > OK, in GIL-compatibility mode I can add a global lock for all Cython > code (which would then be a global lock for all cdef data). This > still won't be exactly equivalent to CPython, though; since IronPython > has no GIL, I can't block pure-Python code from running simultaneously > with Cython code. So Cython code that assumes (for example) that it > holds a lock on all Python dictionaries (including module > dictionaries), by virtue of holding the GIL, could break.
Right. I think the requirement here is more like a lock for Cython code, but global to the system. While it is true that the GIL prevents the execution of /any/ Python code while an extension holds it, I would expect that the most important property is that it prevents other threads from executing parts of the extension itself. > This would be good enough for the "Fast, re-entrant, optimistic lock" > you linked to, since it's manipulating cdef data (although it wouldn't > be as fast any more, since it's adding an extra lock/unlock on every > method call). It would basically degrade into the normal RLock implementation, as a lock would have to be required on each request, independent of the low-level lock that the FastRLock class wraps internally. > Does your code assume that the Cython GIL locks Python data > structures, or only cdef data structures? It only assumes that no-one can enter the lock/unlock methods while they are being executed (unless they call into Python code). That's the main property that I keep using in my own code, and I think the main property of the GIL from the POV of most extensions. So it basically protects all C level structures from nondeterministic concurrency. >>> CPython could get its act together with a LLVM backend etc., but it >>> would be nice strategically to have Mono available as a competing >>> platform, in case CPython doesn't manage to improve matters. >> >> That would be one heck of a dependency, though. I don't know how big LLVM >> is, but I would expect it to be a lot smaller than Mono. > > I was curious, so I did some checking. According to PEP 3146, Unladen > Swallow adds a little over 10 megabytes to the size of the Python > binary. That's a lot more than I expected. Pretty huge in absolute numbers. > When I add together the Installed-Size of the recursive mono > dependencies for IronPython (not including IronPython itself) on my > Debian system, I get 23 megabytes; but that includes implementations > of the Windows Forms and a bunch of web stuff. If it were repackaged > to split out the parts of IronPython that depend on those libraries, > it looks like mono (including the JIT and the core libraries) would be > more like 15 megabytes. So it's basically in the same ball-park as LLVM. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
