Foreign.funptr should require runtime_lock argument

[dsheets]

Right now, Foreign.funptr has an optional argument ?runtime_lock. This parameter has no 'obvious' default value because its use is very context-dependent and its correct use is critical with non-obvious behavior when wrong. Because of this, I believe runtime_lock should not be optional.

[dbuenzli]

Also the documentation of foreign's release_runtime_lock and funptr's runtime_lock is quite confusing when read in conjunction. For one thing they both start with exactly the same sentence but they have exactly the converse meaning:

• for foreign, release_runtime_lock:true means release the runtime lock
• for funptr, runtime_lock:true means acquire the runtime lock.

Maybe funptr's runtime_lock:'s label should be changed to an assertive label to make it more clear, like hold_runtime_lock: or acquire_runtime_lock:.

[yallop]

Maybe funptr's runtime_lock:'s label should be changed to an assertive label to make it more clear, like hold_runtime_lock: or acquire_runtime_lock

I've thought about doing this, but the behaviour of the argument depends on whether the funptr is used in a positive or negative position. In the following example, one of the runtime_lock arguments indicates that the lock should be acquired during the call, and the other indicates that the lock should be released:

funptr ~runtime_lock:true
  (funptr ~runtime_lock:true (int @-> returning int) @-> returning int)

[dbuenzli]

I've thought about doing this, but the behaviour of the argument depends on whether the funptr is used in a positive or negative position.

I see. I still think that the documentation of funptr should make this much more clear.

Also maybe having something like flip_runtime_lock or invert_runtime_lock makes it at least sound that the meaning depends on some kind of current "state".

[dbuenzli]

(even though I'd agree this terminology has no standard meaning on a lock in general).