Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] opcode deinit

There will be a lot of change in the API, which will not be backward compatible, I'm afraid.

The best we can do is make sure, within the constraints we have, is that all the required functionality is there. Sometimes this will be provided in a different form.

A few things had to go, though, because they were opening up vulnerabilities in the library. I don't think they affected your use cases. Since you are a heavy user of both the module and the host APIs, you might want to have a look at the PRs that are in process and that will come up.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 28 Mar 2024, at 07:13, Eduardo Moguillansky <[email protected]> wrote:


I have code which, at the moment, needs to register deinit calls dynamically, the actual routine depends on the arguments passed. It can be adapted to using a static callback, so if there is a need to remove the API call, it's fine.  It would be great if deinit is called while the arguments to the opcode are still valid

On Wed, Mar 27, 2024 at 10:06 AM Victor Lazzarini <[email protected]<mailto:[email protected]>> wrote:
We can make sure the deinit happens before the other cleanup if this is important.

Why would we keep the callback? It seems to me that we should offer one way to deinit, not two.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 27 Mar 2024, at 06:12, Eduardo Moguillansky <[email protected]<mailto:[email protected]>> wrote:


Please don't remove the API call.

 One thing that is not clear about deinitialization is what is guaranteed to exist at this point. For example, should  an opcode be able to read its arguments at this point? For example I tried implementing a "defer" opcode, somewhat similar to go's defer, and found that reading input arguments could lead to invalid memory access.

On Wed, Mar 27, 2024, 00:31 Victor Lazzarini <[email protected]<mailto:[email protected]>> wrote:
Thanks for the feedback, Mike and Steven.
I’ll get to that soon. It should not be too difficult.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 26 Mar 2024, at 19:33, Steven Yi <[email protected]<mailto:[email protected]>> wrote:
>
> *Warning*
>
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>
> I'm in favor of this, it's a much clearer design. I'd also recommend
> removing csoundRegisterDeinitCallback() from the API.
>
> On Tue, Mar 26, 2024 at 10:35 AM Victor Lazzarini
> <[email protected]<mailto:[email protected]>> wrote:
>>
>> Hi all,
>>
>> I have been thinking that we could regularise the opcode api by adding an (optional) deinit field
>> in OENTRY.
>>
>> At the moment, opcodes requiring deinit need to explicitly register a callback with Csound. While this
>> works, it seems a bit awkward.
>>
>> Since we have already removed the use for the “a” function field in the OENTRY, I thought we may
>> be able to reuse it for this purpose. For example,
>>
>> OENTRY o = { “name”, S(STATE), 0,  3,  "a",  “aki", init_func, perf_func, deinit_func};
>>
>> Not all opcode need this, but for the ones who do, this seems a more natural way to set it up.
>>
>> The current deinit routine for an instrument is:
>>
>> /* call the opcode deinitialisation routines of an instrument instance */
>> /* called from deact() in insert.c */
>> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
>> {
>>    int err = 0;
>>
>>    while (ip->nxtd != NULL) {
>>      opcodeDeinit_t  *dp = (opcodeDeinit_t*) ip->nxtd;
>>      err |= dp->func(csound, dp->p);
>>      ip->nxtd = (void*) dp->nxt;
>>      free(dp);
>>    }
>>    return err;
>> }
>>
>> and we would possibly modify it to be something simple like this:
>>
>> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
>> {
>>   int err = 0;
>>   OPDS dds = (OPDS *) ip;
>>   while ((dds = dds->nxtp) != NULL)
>>    err |= (*dds->dopadr)(csound, dds);
>>   return err;
>> }
>>
>> or thereabouts.
>>
>> Any thoughts?
>> ========================
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>