-
-
Notifications
You must be signed in to change notification settings - Fork 343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arbitrary kevent support #578
Comments
Okay, I think I've swapped this back into my brain now, and looking at #579... First, the thing where But, looking at it again, though, I'm not sure this is a great plan. There are two cases I know of where kevent filters can magically get registered without using
So, never mind all that. Let's drop I think we probably want to public functions: one that listens for a single ONESHOT event, and one that listens for events on an ongoing basis. The first can probably be a simple wrapper around the second (that listens until it hears one event and then returns). For the latter... that's basically what #579 makes One more wrinkle: how So I'm wondering if we should replace the @attr.s
class KqueueMonitor:
data = attr.ib(default=attr.Factory(list))
closed = attr.ib(default=False)
waiter = attr.ib(default=None)
def _append(self, event):
self.data.append(event)
if self.waiter is not None:
_core.reschedule(self.waiter)
def _close(self):
self.closed = True
if self.waiter is not None:
_core.reschedule(self.waiter)
def __aiter__(self):
return self
async def __anext__(self):
if not self.data and not self.closed:
if self.waiter is not None:
raise ResourceBusyError
task = _core.current_task()
self.waiter = task
def abort_fn(_):
self.waiter = None
return _core.Abort.SUCCEEDED
await _core.wait_task_rescheduled(abort_fn)
if self.data:
data = self.data
self.data = []
return self.data
assert self.closed
raise ClosedResourceError |
This is part of the long term plan to implement subprocess suport as outlined in #4 (comment) (see "Step 3", copied/pasted below for convenience).
On MacOS and the BSDs, there's this neat thing called "kqueue", which lets you efficiently wait on all kinds of different events in an async-event-loop-friendly way. Currently Trio just uses this to wait for file descriptors to become readable/writable, but in general kqueue is much more flexible. For example, the
EVFILT_PROC
event type lets you wait for a subprocess to exit.trio/_core/_io_kqueue.py
should provide the ability to wait on arbitrary event types. (Then we'll use that in our subprocess support to wait forEVFILT_PROC
events.)There's already a stub implementation of this, in the
monitor_kevent
method. This isn't tested or used currently though, so if we're going to start using it we'd want to make sure it actually works. (And possibly change how it works, if there's some other semantics that make it easier to use.)The text was updated successfully, but these errors were encountered: