Re: DiskIO_UGen glitch

> so it may need another lock just for communication between they two
> when it touches a particular resource
Curiously, Supernova already has a mutex for each SndBuf, see
"async_buffer_guards" in "sc_plugin_interface". Asynchronous commands
like /b_alloc, /b_read or /b_close all take such lock in the NRT phase,
although I don't see what they are trying to protecting against (I can't
find any other calls to "buffer_guard" outside of "sc_osc_handler.cpp").

Now, if those SndBuf locks where also present in Scsynth and if they
were accessible via the plugin interface*), then DiskIO ugens could just
grab the corresponding SndBuf lock instead of having to lock the whole
NRT thread.

Christof

*) the locks themselves probably shouldn't be exposed, it's enough to
provide two plugin API methods: fAcquireNRTBuf and fReleaseNRTBuf

On 26.02.2020 15:25, [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.
>