threading.Event.wait_unset()

[JacobKunnappally]

BPO	40871
Nosy	@blacklight

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-06-05.13:42:51.816>
labels = ['type-feature', 'library', '3.10']
title = 'threading.Event.wait_unset()'
updated_at = <Date 2020-09-25.14:00:30.112>
user = 'https://bugs.python.org/JacobKunnappally'

bugs.python.org fields:

activity = <Date 2020-09-25.14:00:30.112>
actor = 'BlackLight'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-06-05.13:42:51.816>
creator = 'Jacob Kunnappally'
dependencies = []
files = []
hgrepos = []
issue_num = 40871
keywords = []
message_count = 2.0
messages = ['370761', '377492']
nosy_count = 2.0
nosy_names = ['Jacob Kunnappally', 'BlackLight']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue40871'
versions = ['Python 3.10']

[JacobKunnappally]

Just requesting a threading.Event.wait_unset(timeout=None) function. I would request the same for multiprocessing.

My use case:

I've made my own class that adds a little bit of IPC plumbing to the base Process class (ChildProcess). Each ChildProcess has a status that it can update to let other threads/processes know what it's doing at the moment. There is a configurable period when that updated status can be considered "fresh". In some cases, I would like a listening process to be able to ignore the "freshness" and only trigger some action only if the status updates while the listening process is waiting for it to update.

To do this, I need to be able to know when the status goes unfresh so that waiting for the status to update can begin in earnest. Right now I am polling manually, and that can't be the right answer.

Happy to clarify the above paragraphs. That's as best as I could think to describe it in text.

[BlackLight]

+1

I have similar applications (both using multithreading and multiprocessing) which rely upon waiting for events to be both set and unset. Some example common pattern:

from multithreading import Thread, Event, Queue
import time

q = Queue()
reading = Event()

def read_from_device(device):
    # Wait for the caller to signal that it's ready to receive
    reading.wait()
    data = get_data(device)

    while data:
        data = get_data(device)
        q.put(data)

    # Once we're done receiving data, wait for the caller to
    # signal that it has received everything
    while reading.is_set():
        time.sleep(1)

    # Do some other operations once all threads are in sync
    release_device(device)

processor = threading.Thread(target=read_from_device, args=(device,))
processor.start()

# Do something else

reading.set()

# Get data from the processor
data = q.get()
while data:
    preprocess_data(data)
    data = q.get()

# Do something before we're ready to clean up everything
process_data()

# Signal to the processor that we're done
reading.clear()

Events (and I'd say that this also applies to Conditions) are supposed to be symmetric - one can either wait for an event to be set or cleared - but the implementation provided by the current API is definitely asymmetric - wait() can be used to wait for an event to be set, but if you want to wait for it to be cleared then the only provided approach is through a poll on is_set().