sturlamolden wrote:
> On Jun 4, 10:11 pm, Josiah Carlson <[EMAIL PROTECTED]>
> wrote:
>
>> However, locking isn't just for refcounts, it's to make sure that thread
>> A isn't mangling your object while thread B is traversing it.
>
>
>> With
>> object locking (course via the GIL, or fine via obje
sturlamolden wrote:
> On Jun 4, 10:11 pm, Josiah Carlson <[EMAIL PROTECTED]>
> wrote:
>
>> lock = threading.Lock()
>>
>> with lock:
>> #synchronized block!
>> pass
>
> True, except that the lock has to be shared among the threads. This
> explicit initiation of an reent
On Jun 4, 10:11 pm, Josiah Carlson <[EMAIL PROTECTED]>
wrote:
> However, locking isn't just for refcounts, it's to make sure that thread
> A isn't mangling your object while thread B is traversing it.
> With
> object locking (course via the GIL, or fine via object-specific locks),
> you get the
On Jun 4, 10:11 pm, Josiah Carlson <[EMAIL PROTECTED]>
wrote:
> lock = threading.Lock()
>
> with lock:
> #synchronized block!
> pass
True, except that the lock has to be shared among the threads. This
explicit initiation of an reentrant lock is avoided in a Java
synchr
sturlamolden wrote:
> On Jun 4, 3:10 am, Josiah Carlson <[EMAIL PROTECTED]>
> wrote:
>> From what I understand, the Java runtime uses fine-grained locking on
>> all objects. You just don't notice it because you don't need to write
>> the acquire()/release() calls. It is done for you. (in a simi
On Jun 3, 9:10 pm, Josiah Carlson <[EMAIL PROTECTED]>
wrote:
>
> If you are doing string searching, implement the algorithm in C, and
> call out to the C (remembering to release the GIL).
I considered that, but...ick! The whole reason I'm writing this
program
in Python in the first place is so I
On Jun 4, 3:10 am, Josiah Carlson <[EMAIL PROTECTED]>
wrote:
> [EMAIL PROTECTED] wrote:
> > I've recently been working on an application[1] which does quite a bit
> > of searching through large data structures and string matching, and I
> > was thinking that it would help to put some of this CPU-in
[EMAIL PROTECTED] wrote:
> I've recently been working on an application[1] which does quite a bit
> of searching through large data structures and string matching, and I
> was thinking that it would help to put some of this CPU-intensive work
> in another thread, but of course this won't work becau
On Jun 3, 5:52 pm, Steve Howell <[EMAIL PROTECTED]> wrote:
> The pitfall here is that to reduce code duplication,
> you might initialize certain variables in a method
> called by __init__, because your object might want to
> return to its initial state.
This is a good point. I was thinking that
--- "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> One random idea is to for Python 3000, make the
> equivalent of
> __slots__ the default, *but* instead gather
> the set of attributes from all member variables set
> in __init__.
Are you suggesting to do this at startup time or
runtime?
The
Hi,
I've recently been working on an application[1] which does quite a bit
of searching through large data structures and string matching, and I
was thinking that it would help to put some of this CPU-intensive work
in another thread, but of course this won't work because of Python's
GIL.
There's
11 matches
Mail list logo
