All Manuals > LispWorks Foreign Language Interface User Guide and Reference Manual > 4 Advanced Uses of the FLI > 4.8 Block objects in C (foreign blocks)


4.8.3 Scope of invocation

In principle, in the general case each of these is not defined:

The implementation of foreign blocks copes with all of these, that is it can work concurrently on any thread and after the block was released/freed, as long as there are live copies of it (except with blocks created by with-local-foreign-block). However, whether the code inside the block can cope with it is dependent on the code. This needs to be considered when creating blocks.

Specific foreign functions that take blocks as argument should be documented to state the scope of invocation. Apple's documentation commonly states whether the code is invoked concurrently or serially. In some functions the caller can decide when it calls the function whether the code can be executed concurrently or not. If you pass the block to a function that is documented to execute it serially, or you can tell it to do it, then you can assume that function that you made the block with is not going to be called concurrently from the block. Otherwise it must be able to cope with concurrent calls from the blocks.

Whether the code may be invoked on another thread or after the function that took the block returned is not normally documented. In many cases it can be deduced with confidence: when you dispatch a block to a queue (for example dispatch_after and similar functions, see the Apple documentation) it clearly can be invoked from another threads after the function returns. In the case of qsort_b (see Apple documentation and the example in (sys:example-file "misc/foreign-blocks.lisp") ) we can be sure that the code will not be invoked after qsort_b returned, because the arguments to the block are based on the data (first argument to qsort_b ), and qsort_b and its callees cannot be guaranteed that the data is still valid once qsort_b returned. On the other hand, we cannot be sure that the block is not invoked on another thread(s) before qsort_b returns. Currently it is probably always called in the same thread where qsort_b was called, but the interface does not guarantee it.

Thus when you create a foreign block in Lisp, the following considerations apply to the Lisp function function that you supply:

LispWorks Foreign Language Interface User Guide and Reference Manual - 7 Dec 2011