[Thread-SIG] Re: [Python-Dev] Re: marking shared-ness

Bill Tutt billtut@microsoft.com
Fri, 21 Apr 2000 09:50:47 -0700


> From: Milton L. Hankins [mailto:mlh@swl.msd.ray.com]
> 
> On Fri, 21 Apr 2000, Christian Tismer wrote:
> 
> > Are you shure that every thread user shares your opinion?
> > I see many people using threads just in order to have
> > multiple tasks in parallel, with none or quite few shared
> > variables.
> 
> About the only time I use threads is when 
>   1) I'm doing something asynchronous in an event loop-driven 
> paradigm 
>      (such as Tkinter) or 
>   2) I'm trying to emulate fork() under win32
> 
    3) I'm doing something that would block in an asynchronous FSM. (e.g.
Medusa, or an NT I/O completion port driven system)

> > Since Python has nothing really private, this implies in
> > fact to protect every single object for free threading,
> > although nobody wants this in the first place to happen.
> 
> How does Java solve this problem?  (Is this analagous to 
> native vs. green
> threads?)
> 

Java allows you to specifically mention whether something should be
seralized or not, and no, this doesn't have anything to do with native vs.
green threads)

> > Python is not designed for that. Why do you want to enforce
> > the impossible, letting every object pay a high penalty
> > to become completely thread-safe?
> 
> Hmm, how about declaring only certain builtins as free-thread 
> safe?  

incref/decref are not type object specific, they're global macros.
Making them methods on the type object would be the sensible thing to do,
but would definately be non-backward compatible.

Bill