The ffiDtor doc still claimed the generated destructor "calls
destroyFFIContext", but it now uses the recycle path. Replaced that line
with a concise note that the slot is recycled for reuse (bounding fd
usage) and that the call is non-blocking — RET_OK once accepted, real
outcome via callback. Switched the example placeholder from Waku to a
generic MyLibObj, and dropped the duplicate inline comment in the body.
Addresses PR #74 review comment r3363200458.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The reuse branch in createFFIContext only fires for a parked slot, and a
slot is only parked by releaseFFIContext. The generated destructor was
still calling destroyFFIContext (full teardown, marks the slot
uninitialised), so the reuse path never triggered and the fd-leak fix was
inert in the generated API.
Switch ffiDtor to releaseFFIContext so the worker and its fds survive the
destroy and get reused on the next create. This is safe because the
framework handles one request at a time: by the time the destructor runs
the worker is idle, not mid-request, so parking cannot race a handler.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* protect against mem leak in case of failures sending requests to ffi thread
* better cleanup if failures in createFFIContext
* avoid dangling cstring in handleRes under ARC/ORC
* better resource cleanup in destroyFFIContext
* invoke onNotResponding if failure in destroyFFIContext
* correct seq copy in alloc
* make sure the lock is init before cleanUpResources
* better possible exception handling in processReq
* guard allocSharedSeq if given seq is empty
* enhance error handling in ffi_context
* add new tests and some corrections
