[Raymond]
>> While this is a somewhat rough approach, it is dramatically
>> simpler than the alternatives (i.e. wrapping locks around every access to a
>> resource or feeding all resource requests to a separate thread via a Queue).
[Alexander]
> Why is that actually more difficult to write? Consid
On Mon, 13 Mar 2006 21:57:59 -0500, Raymond Hettinger wrote:
> Think of it as "non-cooperative"
> multi-threading. While this is a somewhat rough approach, it is dramatically
> simpler than the alternatives (i.e. wrapping locks around every access to a
> resource or feeding all resource request
Raymond Hettinger wrote:
> Once place where we already have CPython specific support is in
> sys.setcheckinterval(). That suggests adapting that function or adding a new
> one to temporarily stop switching, almost the same as
> sys.setcheckinterval(sys.maxint) but continuing to perform other p
[Phillip J. Eby]
> Well, I'm showing my age here, but in the good ol' days of the 8086
> processor, I recall it frequently being used to describe a block of
> assembly code which ran with interrupts disabled - ensuring that no task
> switching would occur.
According to Wikipedia's current article
On 3/14/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:21 PM 3/14/2006 -0500, Tim Peters wrote:
> >The common meaning is:
> >
> > a section of code such that, once a thread enters it, all other
> > threads are blocked from entering the section for the duration
>
> That doesn't seem l
[Raymond Hettinger]
> ...
> I disagree that the need is rare. My own use case is that I sometimes
> add some debugging print statements that need to execute
> atomically -- it is a PITA because PRINT_ITEM and PRINT_NEWLINE
> are two different opcodes and are not guaranteed to pair atomically.
Wel
At 02:21 PM 3/14/2006 -0500, Tim Peters wrote:
>There _is_ some variation in what "critical section" means, exactly,
>to different thread programming cultures, but in none does it mean:
>
> a section of code such that, once a thread enters it, all other
> threads are blocked from doing anyt
[Raymond Hettinger]
>> FWIW, the new with-statement makes the above fragment even more
>> readable:
>>
>> with atomic_transaction():
>> # do a series of steps without interruption
[Phillip J. Eby]
> +1 on the idea, -1000 on the name. It's neither atomic nor a
> transaction. I believe
On 3/14/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
Once place where we already have CPython specific support is insys.setcheckinterval(). That suggests adapting that function or adding a newone to temporarily stop switching, almost the same assys.setcheckinterval
(sys.maxint) but continuing
[Nice analysis from Michael Chermside]
> The concept of a "critical section" makes great sense when there is
> effectively only one CPU: just stop switching threads. But if code
> is using multiple CPUs, what does it mean? Shut down the other CPUs?
. . .
> I think it is unwise to build such a
> fe
Josiah Carlson writes:
> It would be nice if Jython or IronPython could (and would) implement
> these 'critical sections'. Whether they can or not, I think that it
> would be a useful feature in the CPython runtime.
The issue is not whether Jython and IronPython "will", it's whether
they "can". E
Samuele Pedroni <[EMAIL PROTECTED]> wrote:
>
> Raymond Hettinger wrote:
>
> > [Samuele Pedroni]
> >
> >> there's no sys.checkinterval in Jython. Implementing this would need the
> >> introduction of some kind of GIL implementation in Jython, the JVM
> >> has no primitive for global critical sec
On Tue, 2006-03-14 at 00:36 -0500, Raymond Hettinger wrote:
> [Guido]
> > Oh, no!
>
> Before shooting this one down, consider a simpler incarnation not involving
> the
> GIL. The idea is to allow an active thread to temporarily suspend switching
> for
> a few steps:
[...]
> I disagree that th
On Mon, 2006-03-13 at 21:06 -0800, Guido van Rossum wrote:
> Oh, no! Please!
>
> I just had to dissuade someone inside Google from the same idea.
Heh... that was me... I LOL'ed when I saw this... and no, I didn't put
Raymond up to it :-)
> IMO it's fatally flawed for several reasons: it doesn't
Raymond Hettinger wrote:
> [Samuele Pedroni]
>
>> there's no sys.checkinterval in Jython. Implementing this would need the
>> introduction of some kind of GIL implementation in Jython, the JVM
>> has no primitive for global critical sections.
>
>
> Wouldn't Java implement this directly by suspend
[Samuele Pedroni]
> there's no sys.checkinterval in Jython. Implementing this would need the
> introduction of some kind of GIL implementation in Jython, the JVM has no
> primitive for global critical sections.
Wouldn't Java implement this directly by suspending and resuming the other
threads (b
Raymond Hettinger wrote:
>>it doesn't translate reasonably to Jython or IronPython, it's really tricky
>>to
>>implement,
>
>
> FWIW, someone on the newsgroup suggested implementing this via a slight
> modification to sys.checkinterval(). The idea was that a None argument would
> translate to
> it doesn't translate reasonably to Jython or IronPython, it's really tricky
> to
> implement,
FWIW, someone on the newsgroup suggested implementing this via a slight
modification to sys.checkinterval(). The idea was that a None argument would
translate to "stop-checking" and the active thre
<[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, March 14, 2006 12:06 AM
Subject: Re: [Python-Dev] Threading idea -- exposing a global thread lock
Oh, no! Please!
I just had to dissuade someone inside Google from the same idea.
IMO it
On Mon, 2006-03-13 at 23:06 -0500, Phillip J. Eby wrote:
> +1 on the idea, -1000 on the name. It's neither atomic nor a
> transaction. I believe that "critical section" is a more common term for
> what you're proposing.
>
> Probably the primitive could be placed in the thread or threading mod
Oh, no! Please!
I just had to dissuade someone inside Google from the same idea.
IMO it's fatally flawed for several reasons: it doesn't translate
reasonably to Jython or IronPython, it's really tricky to implement,
and it's an invitation for deadlocks. The danger of this thing in the
wrong hands
At 09:57 PM 3/13/2006 -0500, Raymond Hettinger wrote:
>FWIW, the new with-statement makes the above fragment even more readable:
>
> with atomic_transaction():
> # do a series of steps without interruption
+1 on the idea, -1000 on the name. It's neither atomic nor a
transaction. I b
A user on comp.lang.python has twisted himself into knots writing
multi-threaded
code that avoids locks and queues but fails when running code with non-atomic
access to a shared resource. While his specific design is somewhat flawed, it
does suggest that we could offer an easy way to make a blo
23 matches
Mail list logo
