A bunch of questions about RizinTask and task system within rizin

[karliss]

A bunch of silly questions mostly for @thestr4ng3r , but hopefully this will help other devs who aren't fully familiar with the current state of task system within Cutter and Rizin.

Need for this started while discussing #3017, but discussing all of them might be out of scope for that PR. (Will continue with questions in separate comments so that they can be answered and discussed separately)

[karliss]

Not exactly. The core can only be held locked by one thread at a time. But it is possible to do this start+join pattern concurrently multiple times and the running tasks will be scheduled in an interlocked fashion. Also it is possible to break such a running task.

But the current thread calling Cutter::functionTask (not async version) will still block. And if multiple threads try to do that all of them (except maybe one) will block just like with locking core directly. Is the idea that it doesn't block other threads which want to use the async version from creating and queuing their tasks?

[thestr4ng3r]

Yes.
The RunScriptTask is probably a good example for that:

void RunScriptTask::runTask()
{
    if (!this->fileName.isNull()) {
        log(tr("Executing script..."));
        Core()->functionTask([&](RzCore *core) {
            rz_core_run_script(core, this->fileName.toUtf8().constData());
            return nullptr;
        });
        if (isInterrupted()) {
            return;
        }
    }
}

Whenever the rz_core_run_script() here calls rz_core_task_yield() or rz_core_task_sleep_begin(), other tasks may be dispatched. So for instance you could run other shorter queries in between, and using RzCoreLocked also will not strictly have to wait until the script has completely finished.

That begin said, the RunScriptTask is a bit excessive in the sense that it starts a thread only to start a task and then block while waiting for that. This could probably be solved nicer with just a RizinFunctionTask, but would need a bit of refactoring since the script running also makes use of AsyncTaskDialog for example.

[karliss]

How much of the rz_core_task API is thread safe? At least some of them are protected by tasks_lock_enter.

Creating a new task calls core_task_ctx_init which calls rz_cons_context_break_push is that safe?

[thestr4ng3r]

Not much of it actually. Usually, you would start new tasks from within another one (including the implicit main task), in which case you have exclusive access to the RzCore anyway, and in Cutter you can reach that for example by using RzCoreLocked.

Functions that then should be thread-safe for valid use-cases are:

• rz_core_task_join()
• rz_core_task_decref()
• rz_core_function_task_get_result() and rz_core_cmd_task_get_result()

rz_cons_context_break_push() might be thread safe, but if the functions are limited to the above, it would not have to be.
But regarding RzConsContext, while RzCons is global to the core (and unfortunately even to the process due to the singleton), RzConsContext is always local to a single task.

However it seems like Cutter is not starting the tasks right in some cases currently. It would have to call the rz_core_task_new functions inside another task (for example in RzCoreLocked) but it does not always do that.

[karliss]

How can cons_break stack function as stack if after creating the tasks they can be started and finished in arbitrary order?

[thestr4ng3r]

RZ_API void rz_cons_break_push(RzConsBreak cb, void *user) {
	rz_cons_context_break_push(I.context, cb, user, true);
}

RZ_API void rz_cons_break_pop(void) {
	rz_cons_context_break_pop(I.context, true);
}

The actual push/pop happens on the RzConsContext and that is local to a single task. I.context is swapped out during scheduling:

RZ_IPI void rz_core_task_ctx_switch(RzCoreTask *next, void *user) {
	if (next->runner_user) {
		CoreTaskCtx *ctx = next->runner_user;
		if (ctx->cons_context) {
			rz_cons_context_load(ctx->cons_context);
			return;
		}
	}
	rz_cons_context_reset();
}

[karliss]

Ok, makes sense. Didn't notice that creating a task creates new context and the push happens for the newly crated context.