[Vortex] How to access user_data in channel object?

[Robert M. Münch]

Am 10.11.2008, 19:30 Uhr, schrieb Francis Brosnan Blazquez <francis at aspl.es>:

> Ok, I see you point, however this API
> (vortex_channel_set_data/get_data/set_data_full) was added precisely to
> avoid double house keeping and race conditions with memory deallocation.

Hi, yes, I know. Is the call to vortex_channel_new using the above API to store the user-data pointer? If so, what internal hash-key is used? Via this key I would be able to retreive the user-data out of any handler function.

> That is, if you use vortex_channel_set_data, you are telling vortex to
> not touch that data. In the case vortex_channel_set_data_full is used
> with a dealloc function, you are linking your dinamically allocated data
> to the existence of the channel, no matter when/how it was closed.

Yes, but as said I'm speaking about vortex_channel_new call. And there it's not possible to specify a deallocation function. The only way to deal with this data is to handle it in any of the handlers.

> This is really convenient especially for server side were the
> programming is not "linear", that is, the channel can be closed by
> several asynchronous events...
>
> However, if you don't agree, no problem that's only my
> recommendation ;-).

I agree, but if we have an API where I can attach user-data (without having to deal with *_set_data, *_get_data calls) I should have a function to retreive the user-data outside a hanlder function as well.

> I would accept a patch to add an API for accessing
> to these pointers. Let me know if you produce such patch.

I haven't done yet, I will have to take a look into the code. And, I think it should be done for all cases, where I can specify a user-data pointer like for vortex_channel_new.

> Agreed. I would like to point that using vortex_channel_set_data keeps
> contract since the pointer is not touched in any case.
>
> Even vortex_channel_set_data_full can keep the contract since it doesn't
> dealloc the data, only calls the handler. This is up to the handler
> provided by your application to dealloc or not.

Maybe to make it simple and consistent, the best way might be to store the user-data stuff via internal hashkeys using the *_set_data API. In such a case, the *_new API might need an additional parameter to specify the deallocation handler.

And a flag if a channel/connection/... is closed that Vortex should call the deallocation handler or free the user-data ressource. This could be streamlined in a way that if a handler is specified Vortex calls it, else nothing is done.

Regards.

-- 
Robert M. Münch
Mobile: +49 (177) 245 2802
http://www.robertmuench.de