Cooperative thread cancellation stalls indefinitely during blocking ⎕NA calls

Dyalog APL uses a cooperative cancellation model where ⎕TKILL only takes effect when the target thread reaches a safe interruption point. When a thread executes a blocking ⎕NA call to a native library function that does not periodically yield control, the cancellation request remains pending until the call returns — which may be never. This creates a gap between the documented timeout parameters on synchronization primitives (⎕TGET, ⎕TSYNC) and actual thread termination: the waiting thread can time out, but the worker thread continues running uninterrupted, potentially holding locks or file handles.

The language reference confirms that ⎕TKILL is a request, not a guarantee, and that ⎕SIGNAL 1003 only affects the current thread. There is no documented mechanism to forcibly terminate a thread stuck in an uninterruptible system call, nor a way to detect that a thread has become unresponsive to cancellation without polling from another thread.

What is the recommended pattern for ensuring resource cleanup when a worker thread blocks indefinitely in a ⎕NA call? Can an external monitor reliably detect that a thread has stopped responding to ⎕TKILL without modifying the native library? Is there a supported way to impose a hard execution deadline on arbitrary APL code that includes blocking foreign calls?