Veloz wrote: > Unless I missed where you guys were going, I think we got off the main > point. The main question at hand was this: what's the best way (heck, > any way) to implement a sort of "peek" whereby a number of processes > can write results to some common "object" and some other process can > "peek" into this object, looking for specific items they're interested > in? I have used threads so far and not multiprocessing (much), so I'll describe it using threads: If I were you, I'd do it the simplest possible way, with dictionary and lock, in the following way: 1. Have shared "queue" of tasks, say, a dictionary. 2. Each worker thread and central "queue manager" access the queue in the same manner: ...do your stuff, prepare yourself acquire a lock update or read value from queue ...don't do much here to be able release lock quickly release the lock ...process value If you had your dictionary simple, it could work like Daniel Stutzbach wrote, that updates are thread safe and perhaps you could even dispense with locks and just read the dictionary; and if you wanted to use locks, for "peek"ing you could write a function that could e.g. acquire a lock, do a copy of the queue, release the lock, and return the copy to the object wanting to examine the queue. I have used this approach (although with a list, not a dictionary -- I haven't had the need to do extensive searching by keys) and so far it has worked for me. Regards, mk
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