Is it possible to return promise in callback?

[neko-para]

I'm not starting using ffi-rs yet. I'd like to check this feature before starting binding.

Is it possible to return a promise in callback function, and let ffi-rs to sync wait it? Generally, I'd like to call some sync blocking function with runInNewThread inside a callback, and the callback should block until these functions finish.

It's required to call those functions asyncly, or deadlock will happen.

[neko-para]

demo calling hierarchies

• js call c func with runInNewThread
  • c call js func
    • js call another c func with runInNewThread
    • js return a promise
  • is it possible for ffi-rs to await the returning promise here, performing sync block?

[zhangyuang]

If a function returns promise means it's an async function. The Async function should not block the main thread in Node.js.
If you want to block the main thread when calling ffi-rs with runInNewThread. Maybe you can run an endless loop in the main thread, and break it when ffi call ends

[neko-para]

If a function returns promise means it's an async function. The Async function should not block the main thread in Node.js. If you want to block the main thread when calling ffi-rs with runInNewThread. Maybe you can run an endless loop in the main thread, and break it when ffi call ends

No, this is not what I mean.

What I want is to block the thread before the async js callback finished, then resume the underlying c callback to continue.

[neko-para]

The main problem is that when main thread of nodejs got blocked in a sync c function, no callback can be called (they are enqueued), thus deadlock occurs

[zhangyuang]

还是没太能理解你的问题，或许你可以用中文再描述一遍(

[neko-para]

• js异步调用c函数
  • 在c函数触发的回调中
    • js异步调用另一个c函数
    • 这里js不得不返回一个Promise
  • ffi-rs在这里应该会将js返回的值转化为c的值, 目前应该是简单的类型转化, 我的意思是这里能否支持同步阻塞等待Promise完成

[neko-para]

ffi-rs在处理的时候是出于触发回调的线程, 即非主线程, 因此应当是可以进行阻塞的

[zhangyuang]

你指的js异步调用c函数是否指的是通过 runInNewThread配置来调用。
c语言的ffi_call是一个同步方法。
默认情况下ffi-rs会同步的在当前线程调用 ffi_call，即会阻塞当前主线程。

当你使用runInNewThread时，ffi-rs会在底层开辟新的独立线程来调用ffi_call。此时主线程不会被阻塞将返回一个promise。当新线程的ffi_call调用结束时promise对象被resolve。

你说的场景似乎有点复杂，或许可以用ffi-rs或者ffi-napi写一个简单的代码示例方便我理解。

[neko-para]

ffi-rs侧用的是伪代码

load('call_callback_and_eval', [async () => {
  await load('another_function', [], runInNewThread)
  return 1
}], runInNewThread)

void call_callback_and_eval(int (*func)()) {
  std::thread([func]() {
    std::cout << func() << std::endl;
  });
}

void another_function() {
  // some action that will block
}

[zhangyuang]

这个调用链路看起来很奇怪。
1、ffi是为了在js中调用c函数，你既然call_callback_and_eval已经在c函数环境了，为什么还要通过调用 func也就是另一个ffi-rs的load方法来调用另一个c函数another_function而不是直接在call_callback_and_eval调用another_function
2、 std::thread和runInNewThread的功能似乎重复了

[neko-para]

因为call_callback_and_eval实际上是注册了一个自定义逻辑, 然后在自定义逻辑实际被使用的地方, 会由js进行控制, 然后在控制的时候可能会用到别的函数

[neko-para]

call_callback_and_eval的std::thread是模拟一个存储&之后再调用的意思

[zhangyuang]

我将会在端午后继续跟进这个问题，你可以先实际运行试试ffi-rs或者ffi-napi的现有功能能否实现你的需求

[neko-para]

其实因为我之前是用的koffi, 遇到了上面这个问题之后就放弃了
Koromix/koffi#87
所以我在看文档确认关于回调和多线程部分和那边没有太大区别的之后提了这个issue

[zhangyuang]

看了一下koffi实现async的底层原理与ffi-rs不一样，你可以用最简单的代码试试能否在ffi-rs成功调用。由于我现在手边没有电脑我将会在端午后跟进这个问题。如果按照你的描述调用会产生死锁可以提供可运行的最小复现代码