Am 17/08/2022 um 15:10 schrieb Emanuele Giuseppe Esposito:
>
>
> Am 17/08/2022 um 10:04 schrieb Emanuele Giuseppe Esposito:
+/* protect against read in job_do_yield_locked */
+JOB_LOCK_GUARD();
+/* ensure the coroutine is quiescent while the AioContext is changed
>>
Am 17/08/2022 um 10:04 schrieb Emanuele Giuseppe Esposito:
>>> +/* protect against read in job_do_yield_locked */
>>> +JOB_LOCK_GUARD();
>>> +/* ensure the coroutine is quiescent while the AioContext is changed */
>>> +assert(job->pause_count > 0);
>> job->pause_count only shows
Am 05/08/2022 um 11:12 schrieb Kevin Wolf:
> Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben:
>> In order to make it thread safe, implement a "fake rwlock",
>> where we allow reads under BQL *or* job_mutex held, but
>> writes only under BQL *and* job_mutex.
>
> Oh, so the "or
Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben:
> In order to make it thread safe, implement a "fake rwlock",
> where we allow reads under BQL *or* job_mutex held, but
> writes only under BQL *and* job_mutex.
Oh, so the "or BQL" part is only for job.aio_context? Okay.
> The onl
On 7/25/22 10:38, Emanuele Giuseppe Esposito wrote:
In order to make it thread safe, implement a "fake rwlock",
where we allow reads under BQL *or* job_mutex held, but
writes only under BQL *and* job_mutex.
The only write we have is in child_job_set_aio_ctx, which always
happens under drain (so
In order to make it thread safe, implement a "fake rwlock",
where we allow reads under BQL *or* job_mutex held, but
writes only under BQL *and* job_mutex.
The only write we have is in child_job_set_aio_ctx, which always
happens under drain (so the job is paused).
For this reason, introduce job_set
