[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v10 14/21] jobs: protect job.aio_context with BQL and job_mut

From: Emanuele Giuseppe Esposito
Subject: Re: [PATCH v10 14/21] jobs: protect job.aio_context with BQL and job_mutex
Date: Thu, 18 Aug 2022 10:48:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0

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 
>>>> */
>>>> +    assert(job->pause_count > 0);
>>> job->pause_count only shows that pausing was requested. The coroutine is
>>> only really quiescent if job->busy == false, too.
>>> Or maybe job->paused is actually the one you want here.
>> I think job->paused works too.
> Actually it doesn't. At least test-block-iothread
> test_propagate_mirror() fails, for both job->paused and !job->busy. I
> think the reason is that if we wait for the flag to be set, we need to
> actually wait that the job gets to the next pause point, because
> job_pause() doesn't really pause the job, it just kind of "schedules"
> the pause on next pause point.
> So, either we leave pause_count > 0, or somehow wait (I was thinking
> AIO_WAIT_WHILE(job->paused) but that's probably a very bad idea).
> Do you have any suggestion for that?
> Maybe Paolo has a better idea on how to do it?

Additional update: after debugging it a little bit, I figured that there
are places where busy=false and paused=false too. This is clear in
job_do_dismiss and not-so-clear in job_exit (at least for me).

I don't know if this is expected or a bug, because it just means that if
we are draining and the job is completing, there is no way to stop it.

Is it a bug? Or am I missing something?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]