[IronPython] IronPython cs Cpython wrt GIL

[J. Merrill]

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