s_task icon indicating copy to clipboard operation
s_task copied to clipboard

提个问题

Open axhlzy opened this issue 2 years ago • 0 comments

我有一个这样的想法 背景大概是安卓ndk编程中,jni_onload这里的这个线程往往是可以直接使用env去做一些java的操作,如果新创建的线程就需要先 AttachCurrentThread 一下才能正常使用 env

如果能在 jni_onload 函数中注册一个协程任务,然后让协程任务本身为一个死循环,同时处于互斥锁卡住的状态,在ndk编程中的其他线程去处理这个互斥锁,同时携带上需要调用的函数地址,这样实现一个在任意线程中都可以通过消息来实现任何函数的调用都在 jni_onload 这个线程中

以上只是一个举例,这里的应用场景还有比如在逆向 il2cpp unity 中,注册在ui线程,跨线程从其他线程都能修改ui

目前看起来的话 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__, void *arg)->auto{
        LOGD("s_mutex_lock %p %d",&sMutex,sMutex.locked);
        while(true){
            s_mutex_lock(__await__, &sMutex);
            LOGD("s_task_create run");
        }
    }, nullptr);

    s_task_join(__await__,g_stack_main);

    LOGD("JNI_OnLoad -- End -- ");

// 过了一段时间后,其他线程调用
    s_mutex_unlock(&sMutex);

并不会继续协程的执行

axhlzy avatar Apr 13 '22 10:04 axhlzy