Re: DiskIO_UGen glitch

Ah - yes - that sounds familiar. 

Thanks!

Josh

> On Feb 26, 2020, at 10:30, [email protected] wrote:
> 
> 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] <mailto:[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. 
>>