> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4