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! Christian 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. >
signature.asc
Description: OpenPGP digital signature
