Re: DiskIO_UGen glitch

No, the Ugens take different code path depending on
unit->mWorld->mRealTime. In NRT mode, the IO thread is not used and disk
access happens synchronously.

 From what I can tell, the IO thread locks the NRT thread to prevent
asynchronous commands from concurrently modifying the NRT SndBufs. This
shouldn't happen anyway, but it can't trust the user not to mess up.

Christof

On 26.02.2020 16:21, [email protected] wrote:
> It needs to block the whole NRT thread, I believe, to keep the DiskIO
> UGens working in NRT mode.
>
> Josh
>
>
>> On Feb 26, 2020, at 09:25, [email protected]
>> <mailto:[email protected]> wrote:
>>
>> yes, sorry, I saw the code but can't get a clear idea, I'm missing
>> too much of the logic, when you write "when the IO thread receives a
>> message, it locks the NRT thread" I think it blocks for the entire
>> nrt whatever is doing and keeps the io thread waiting for other tasks
>> so it may need another lock just for communication between they two
>> when it touches a particular resource and that io thread only need to
>> know if buffers are ready or not. This is just more vaguely
>> explanation of the same thing, maybe opening an issue could get more
>> answers in time.
>>
>>
>> El mar., 25 feb. 2020 a las 18:02, <[email protected]
>> <mailto:[email protected]>> escribió:
>>
>>     This is a bit vague to be honest...
>>
>>     Christof
>>
>>     On 25.02.2020 21:38, [email protected]
>>     <mailto:[email protected]> wrote:
>>>
>>>
>>>         block on a different lock until the resource ir ready or
>>>         taken? (I do the same disclaimer as contact).
>>>
>>>
>>>     or "to check if" depending of what resource.
>>
>