[EMAIL PROTECTED]
Note that python-bugs-list is a moderated list for use only by
automated reports generated from SourceForge. I'm redirecting the
reply to [EMAIL PROTECTED]
> I have a very strange bug. A thread in a .pyc stops dead.
>
> This program has many threads and queues and has worked
Op 2004-12-14, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2004-12-13, Tim Peters schreef <[EMAIL PROTECTED]>:
>>
>>>[Antoon Pardon]
>>>
I don't see why starting a thread as a side effect of importing is
bad thread practice. Sure python doesn't cater for it, bu
Antoon Pardon wrote:
Op 2004-12-13, Tim Peters schreef <[EMAIL PROTECTED]>:
[Antoon Pardon]
I don't see why starting a thread as a side effect of importing is
bad thread practice. Sure python doesn't cater for it, but IMO
that seems to be python failing.
Obviously, it's bad practice in Python becau
Op 2004-12-13, Tim Peters schreef <[EMAIL PROTECTED]>:
> [Antoon Pardon]
>> I don't see why starting a thread as a side effect of importing is
>> bad thread practice. Sure python doesn't cater for it, but IMO
>> that seems to be python failing.
>
> Obviously, it's bad practice in Python because it
[Antoon Pardon]
> I don't see why starting a thread as a side effect of importing is
> bad thread practice. Sure python doesn't cater for it, but IMO
> that seems to be python failing.
Obviously, it's bad practice in Python because it can lead to
deadlocks in Python. It's nearly tautological. Im
Op 2004-12-12, Tim Peters schreef <[EMAIL PROTECTED]>:
>
> I think you'd have to ask Brett (who did most of the work on
> dummy_thread and dummy_threading). It doesn't really matter, though:
> it's a general truth that starting a thread as a side effect of
> importing is a recipe for deadlock, an
phil wrote:
[...]
> 5. Sorry I can't be more help. You don't give anyone much
> to go on. All that stuff about "Queue(0)" and "listenq"
> is pretty much meaningless to us, you know...
You know, I get this all the time on language support groups.
This might be a clue.
All of my Linux support gr
[Peter Otten]
> What I believe to be a minimal example:
>
>
> import Queue
> import threading
> import time
>
> q = Queue.Queue(4)
>
> def proc():
>while True:
>q.get(1)
>Queue.Queue()
>print "YADDA"
>
> threading.Thread(target=proc).start()
>
> while True:
>pri
phil wrote:
> And sorry I got ticked, frustrating week
>
> >And I could help more, being fairly experienced with
> >threading issues and race conditions and such, but
> >as I tried to indicate in the first place, you've
> >provided next to no useful (IMHO) information to
> >let anyone help y
On Fri, 10 Dec 2004 16:18:51 -0600, phil <[EMAIL PROTECTED]> wrote:
>And sorry I got ticked, frustrating week
>
threading problems can do that ;-)
You are obviusly deeper into this than I can get from a cursory scan,
but I'll make some general debugging comments ;-)
> >And I could help more, bei
phil wrote:
Well its an anomaly. I sent to bug list.
Probably never see it again.
I think some sort of semaphore thingy, which I know
nothing about, is sneaking in under unreproducible
conditions. I'm moving on.
If you want to try one more thing, try mucking with
a call to sys.setcheckinterval().
>You have the source to Queue.py in your standard library
>folder. Why not throw a few more print statements into
>its __init__ and see what you learn?
Yeah I put some print statements in init and it seems
to complete.
>Are you by any chance running on a new version of the
>Linux kernel, where the
phil wrote:
Uses no locks.
It does use locks implicitly, though, since even just
importing threading will do that, and creating a Queue
does too.
I am mystified, I have written probably 100,000 lines
of Python and never seen a thread just lock up and quit
running. It happens on a Queue() statement
And sorry I got ticked, frustrating week
>And I could help more, being fairly experienced with
>threading issues and race conditions and such, but
>as I tried to indicate in the first place, you've
>provided next to no useful (IMHO) information to
>let anyone help you more than this
This is about 5
phil wrote:
I've never before on any group seen anyone told they
had a mental block, because they were fishing for info.
I'm sorry if I offended you by using that term. That
wasn't my intention. Communications can be difficult
in an online forum. For example, I would normally find
the phrase "fi
>Wow, amazing! Imagine that... asking for elaboration when
>someone posts unclear confusing questions and extraneous
>information. The noive!
I would be happy to elaborate. No one asked to me to elaborate.
I was simply told I didn't give enough information.
I wasn't given an idea of what addition
phil wrote:
You know, I get this all the time on language support groups.
All of my Linux support groups, if they don't understand, say
why and ask for elaboration.
Wow, amazing! Imagine that... asking for elaboration when
someone posts unclear confusing questions and extraneous
information. Th
> 4. The fact that you have a .pyc file instead of a .py
> file very likely has *nothing* to do with any threading
> problem you are facing, so I suggest you get past that mental
> block and look elsewhere.
Well, I tried to make it clear that the ONLY difference between
working and not working was
phil wrote:
I have a very strange bug. A thread in a .pyc stops dead.
This program has many threads and queues and has worked
great for months.
One thread listens for UDP messages from other programs,
and puts the messages in listenq.
Procmsgs gets from listenq and for a certain kind of
message cr
I have a very strange bug. A thread in a .pyc stops dead.
This program has many threads and queues and has worked
great for months.
One thread listens for UDP messages from other programs,
and puts the messages in listenq.
Procmsgs gets from listenq and for a certain kind of
message creates anoth
20 matches
Mail list logo
