[Vortex] How to access user_data in channel object?

Francis Brosnan Blazquez francis at aspl.es
Mon Nov 10 19:30:23 CET 2008

Hi Robert,

> That would be the workaround I would use as well. But I don't think
> it's  
> elegant nor consistent.


> I think as you suggested adding an API to access this user-data is
> the  
> most clear way. Because storing something in their but never getting
> it  
> back is a bit strange. 

It is retrieved but on handler activation...Of course it can't be
retrieved in the sense you can't call to a function to get the data..

> Especially if the user-data is something  
> dynamically allocated. And, doing a double-housekeeping, first on my
> own  
> and vortex on its own splits responsibility or at least opens the
> threat  
> for a sideeffect.

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.

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.

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 would accept a patch to add an API for accessing
to these pointers. Let me know if you produce such patch.

> If the contract is clear: Vortex never touches your user-data on its
> own.  
> Than I think an access method is necessary, so that I can free
> dynamically  
> allocated ressources.

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.

Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.

More information about the Vortex mailing list