[IronPython] IronPython cs Cpython wrt GIL

[Levi Cook]

It's pretty clear, despite the performance burden, that lists and
dicts need to be thread safe by default.

Making it configurable is an interesting option. Maybe I didn't follow
correctly, but altering Python's grammar to accommodate this doesn't
feel like a good idea.

Some more options...

a) A system wide runtime config file that the interpreter consults on startup 
b) Use an environment variable
c) A commandline arg
b) IronPython specific builtins (if you really cared you could put
something like this in your pythonrc file)

try:
   list = felist
except NameError:
   list = list

I haven't thought about this enough to say what combination of the
above would be best.  For whatever it's worth, extending Python's
syntax would push me away from IronPython down the road. Then again, I
might have misinterpreted the last message. If so, sorry for rambling
:)

- Levi

On Wed, 13 Oct 2004 16:59:36 -0400, J. Merrill <jvm_cop at spamcop.net> wrote:
> At 11:36 PM 10/12/2004, Jim Hugunin wrote (in part)
> >My area of concern is around the standard objects.  IronPython lists and
> >dictionaries are not currently thread-safe.  This is in line with the CLR
> >collection APIs that assume the developer using lists and dictionaries will
> >handle any needed synchronization.  However, because of Python's GIL, Python
> >lists and dictionaries behave as if they are thread-safe to the Python
> >programmer.  For compatibility with multi-threaded Python programs,
> >IronPython will probably need to use thread-safe lists and dicts for these
> >standard Python objects and this will impose some small but noticeable
> >performance overhead.  I'd like to come up with a more clever solution to
> >this dilemma so that synchronization overhead is only imposed when it's
> >truly needed, but I can't come up with a solution that wouldn't inflict
> >undue compatibility burdens on Python devs.
> >
> >-Jim
> 
> Providing a notation that FePy-specific programs can use to say "I'll handle the synch work" should be enough.  If we don't go to the trouble of adding that notation (and doing the synch work!), we'll get the overhead that's now "enjoyed" by traditional Python developers; if we do, we'll get extra speed (and extra danger if we screw up).
> 
> Of course that means you've got to implement the thread-safe versions, keeping the existing ones around for use when we set that flag.
> 
> Using a CLR-style attribute (ManualSynchAttribute?) would be the .NET clean way for us to make that notation; a comment in a special format would be another (kludgier) way.
> 
> J. Merrill / Analytical Software Corp
> 
> 
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>