• Philip Withnall's avatar
    agent: Support invoking I/O callbacks in non-default contexts · 2b6370a8
    Philip Withnall authored
    If the Component’s I/O receiver machinery is invoked from a thread which
    can’t acquire the main context specified for the I/O callbacks, the
    callbacks need to be queued as idle handlers in that main context.
    This is needed for the case where blocking reads are being performed in
    one thread, with their callbacks needing to be delivered in another
    This introduces a new fine-grained lock to Component: io_mutex. This
    protects accesses to Component->io_callback, Component->io_user_data and
    Component->pending_io_callbacks. If being locked at the same time as the
    main agent lock, it must always be locked afterwards, but the agent lock
    does not *have* to be held in order to lock io_mutex.
agent.c 95.2 KB