Ivan FB 1c2ea72336

feat(ffi): dispatch events on the event thread, not the FFI thread ...

PR #71 stood up the event thread + bounded queue but left dispatch
inline, so a blocking consumer callback stalled request processing on
the FFI thread. Wire the producer side onto the existing queue: the FFI
thread now enqueues (copyToShared/dupSharedCString/enqueueFFIEvent) and
returns immediately; the event thread drains and invokes callbacks under
reg.lock. This keeps the event thread as watchdog *and* dispatcher.

Because callbacks no longer run on the FFI thread, a callback may issue a
synchronous sendRequestToFFIThread without tripping the reentrancy guard
(the FFI thread is separate) — a callback still must not add/remove
listeners on its own registry. A wedged callback fills the queue and
latches eventQueueStuck, which sendRequestToFFIThread surfaces as backpressure.

Reworked the lock-during-invocation test to drive through the real event
thread, and added a test for the now-safe sync-request-from-callback path.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-04 00:21:23 +02:00

..

e2e/cpp

Remove wildcard event listener; keep per-event dispatch (#70)

2026-06-02 22:22:35 +02:00

unit

feat(ffi): dispatch events on the event thread, not the FFI thread

2026-06-04 00:21:23 +02:00