5.7.1 Calling foreign code that receives a block as argument

To call foreign code that needs a block as an argument, the Lisp program needs to create the blocks. You do this in two steps:

1. At load time, define a "type" by using the macro define-foreign-block-callable-type. This "type" corresponds to the "signature" in C.
2. At run time, generate the block, for example by calling allocate-foreign-block with the "type". Alternatively use one of the macros with-foreign-block and with-local-foreign-block. When generating the block, you also pass an arbitrary Lisp function that gets called when the block (or a copy of it) is invoked.

Foreign blocks created by allocate-foreign-block are released when appropriate by free-foreign-block.

Foreign block pointers created by allocate-foreign-block are of type foreign-block-pointer and print with "lisp-foreign-block-pointer".

For examples see:

(example-edit-file "fli/foreign-blocks")

and

(example-edit-file "fli/grand-central-dispatch")

5.7.2 Operations on foreign blocks

You might obtain a foreign pointer of type foreign-block-pointer that was passed as an argument to another foreign block, to a callable defined by define-foreign-callable or returned by a foreign function.

The foreign block can be invoked by defining an invoker (at load time) using define-foreign-block-invoker, and calling the invoker. If you need to keep the block after returning to the caller, you normally need to copy it by foreign-block-copy. If you copy a block, once you are finished with it, you should release it by foreign-block-release.

For examples of this see

(example-edit-file "fli/invoke-foreign-block")

5.7.3 Scope of invocation

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

• The time at which the code that the block encapsulates is invoked. In particular, even after a block is released (freed), the same code may be invoked by a copy of the block.
• In which thread the code is invoked.
• How many invocations can occur in parallel. In other words, whether it is invoked serially or concurrently.

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 (example-edit-file "fli/foreign-blocks")) 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:

• In most cases, function needs to cope with being called in any thread, and hence cannot rely on the dynamic environment. Normally it is impossible to deduce that function will not be called on another thread, so it can be guaranteed only when the function to which the block is passed is documented to guarantee it.

Note: that is the only situation in which it is really valid to use with-local-foreign-block.

• function may need to be able to cope with being called at any time, unless it is documented or deducible from the interface that it can be called only within the scope of the caller. It may be possible to deduce the time limit on a call from the way the block is used.
• The function needs to be able to cope with being called concurrently, unless the documentation of the user of the blocks says that it does not, or you can tell that it is going to be called only on one thread.