On Apr 29, 5:30 pm, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > Terry <[EMAIL PROTECTED]> wrote: > > On Apr 28, 5:30 pm, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > > > David <[EMAIL PROTECTED]> wrote: > > > > Another idea would be to have multiple queues, one per thread or per > > > > message type "group". The producer thread pushes into the appropriate > > > > queues (through an intelligent PutMsg function), and the consumer > > > > threads pull from the queues they're interested in and ignore the > > > > others. > > > > Unfortunately a thread can only wait on one Queue at once (without > > > polling). So really the only efficient solution is one Queue per > > > thread. > > > > Make an intelligent PutMsg function which knows which Queue (or > > > Queues) each message needs to be put in and all the threads will have > > > to do is Queue.get() and be sure they've got a message they can deal > > > with. > > > I do have one Queue per thread. The problem is the thread can not peek > > into the Queue and select msg with certain ID first. > > My point is don't put messages that the thread doesn't need in the > queue in the first place. Ie move that logic into PutMsg. > > -- > Nick Craig-Wood <[EMAIL PROTECTED]> --http://www.craig-wood.com/nick
Well, I'm simulating the real world. It's like that you wouldn't drop or proceed a task when you already started your lunch, just save it and process it later when you finish your lunch. Of course the task sender can send the task again and again if he got not ack from you. But that's just one possible situation in the real world, and not an efficient one. -- http://mail.python.org/mailman/listinfo/python-list
