s_task
s_task copied to clipboard
xhawk18
awaitable coroutine library for C
我有一个这样的想法 背景大概是安卓ndk编程中，jni_onload这里的这个线程往往是可以直接使用env去做一些java的操作，如果新创建的线程就需要先 AttachCurrentThread 一下才能正常使用 env 如果能在 jni_onload 函数中注册一个协程任务，然后让协程任务本身为一个死循环，同时处于互斥锁卡住的状态，在ndk编程中的其他线程去处理这个互斥锁，同时携带上需要调用的函数地址，这样实现一个在任意线程中都可以通过消息来实现任何函数的调用都在 jni_onload 这个线程中 以上只是一个举例，这里的应用场景还有比如在逆向 il2cpp unity 中，注册在ui线程，跨线程从其他线程都能修改ui 目前看起来的话 [s_task](https://github.com/xhawk18/s_task) 只是在指定的一个位置创建了协程并卡住当前线程，只有等到所有join的协程都执行完了才能继续当前线程，且互斥量尽在协程之间使用有效，外部创建的线程修改互斥量好像并不能继续协程的执行 问题落到了：如何在协程处于阻塞状态的时候从其他线程唤醒协程 ``` LOGD("JNI_OnLoad -- Start -- "); s_task_init_system(); s_mutex_init(&sMutex); s_mutex_lock(__await__, &sMutex); s_task_create(g_stack_main,sizeof (g_stack_main),*[](__async__,...
现象为多个send_task发送消息到recv_task，由于chan空间设置太小，导致部分send_task进入等待态，而recv_task在收到第一个消息时正常退出并设置全局变量控制所有send_task退出。此时，剩余send_task不在全局变量的active_task上且由于没有定时器、没有uv的handles和req，uv正常结束流程，导致剩余等待状态的send_task没有正常退出。 不知道这是个bug还是正常使用不会出现这种情况？
vs libuv
你好！ 请问这个工程项目对比libuv有哪些优势？ 我想找到一个比libuv性能更好，支持多核cpu的库。主要应用是python的uvloop，一个libuv的包装，单核性能还可以，希望可以充分利用多核，性能再好些更好了。 谢谢
源码 : #define s_chan_declare(name,TYPE,count) \ s_chan_t name[1 + ((count)*sizeof(TYPE) + sizeof(s_chan_t) - 1) / sizeof(sizeof(s_chan_t))] 不懂为什么是除以sizeof(sizeof(s_chan_t)), 而不是除以sizeof(s_chan_t)
在 void on_connection(uv_stream_t *stream, int status) 中已经对client对象初始化了: s_list_init(&client->list_node); s_list_attach(&server->running_clients, &client->list_node); 在 static void run_client(__async__, void *arg) 中再次初始化: s_list_init(&client->list_node); s_list_attach(&client->server->running_clients, &client->list_node); 重复初始化存在问题.
直接在 `build` 目录里 make 会生成不需要的中间文件。 建议在里面新建下一级目录编译： ``` cd s_task/build mkdir build && cd build cmake -G Ninja .. ninja ``` 这样的话，`build/build` 这个目录可以随时删掉，这样一来 `s_task/build` 这个目录名字就不太合适，容易混淆。
hawk 你好， 最近试用了一下s_task， 感觉很不错， 不过因为对代码的理解有限，还希望能请教几个问题。 ``` char g_stack0[384]; // 64 * 6 char g_stack1[384]; ``` 我测试了一下， `64*5` 的stack， 也可以运行， 但`64*4` 就出现了报错 ` fprintf(stderr, "stack overflow in lower bits");` ``` if(((int...
it would be good to have a possibility to try to acquire a mutex with a timeout (as is possible for an event).
I initialize an event, and then wait on it in a task, using s_event_wait_sec(__await__, &ev, 1); This works (execution proceeds when a timeout occurs or the event is set). However,...
三个opreator：co_await, co_yield, co_return
