[Top][All Lists]

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

Re: CADET API: Obtaining the CADET channel closure?

From: Christian Grothoff
Subject: Re: CADET API: Obtaining the CADET channel closure?
Date: Mon, 24 May 2021 23:59:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

Hi Alessio,

You should store a copy of the 'cls' together with your channel handle.
Typically, the 'cls' would actually point to the struct in which you
store your channel handle. So if you do this in any reasonable way, you
should not need an API to lookup the 'cls' from the handle.

If you can point me to your code and where you need the 'cls', I might
be able to suggest how to do this...

Happy hacking!


On 5/24/21 10:37 PM, Alessio Vanni wrote:
> Hello,
> there might be a better way to do what I'm trying to do, but I couldn't
> really think of it, so here it is:
> I'm opening CADET channels on demand and then stashing them away until
> they are needed again (or closed.) Because those channels require some
> "state" when something is received through them, I give them a closure
> which is unique for each of them and allocated dynamically at the time
> of the channel creation.
> When the other end of the channel shuts down or when the service itself
> terminates, this closure is deallocated through the disconnect callback.
> However, when a channel is closed manually with the `channel_destroy'
> function, this closure would linger and never be deallocated as the
> callback is not called.
> Most of this "state" provided by the closure could actually be provided
> in a different way, but the remaining part would be really inefficient
> without this closure, so for the sake of avoiding having to continuously
> run a for-loop every time certain actions are taken, I'm approaching the
> issue this way.
> Would it be possible to get that closure somehow? As it is right now
> it's impossible, but a way to do it could be added somewhere, if it
> makes sense.
> I see that there is a function to fetch channel options which currently
> returns only the other peer; maybe it could be expanded?
> Thanks,
> A.V.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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