[Vortex] vortex_channel_set_serialize

[Francis Brosnan Blazquez]

Hi Chris,

> I currently have to call vortex_channel_set_serialize(true) to make
> sure my frame handler receives ANS frames in sequential order. The
> default behavior (when I don't call vortex_channel_set_serialize) is
> for the ANS frames to be handed to my frame handler out order. i.e.
> the 1st frame I get is ANS frame 1, the 2nd frame I get is ANS frame
> 0, the 3rd frame I get is ANS frame 2, etc. I can also get the NUL
> frame before all ANS frames are received.
> 
> It appears that the current implementation of Vortex/BEEP may not be
> following the BEEP spec? 

It do follow the spec. This is a threading issue explained at
vortex_channel_set_serialize documentation. Please check it.

Current Vortex implementation is heavily threaded. This has advantages
and sides effects like having the thread planner stopping the thread
that is carrying your ANS 1 reply, and giving priority to the thread
carrying ANS 0. 

> From my understanding, all reply frames (RPY, ERR, ANS) should be
> received in order. 

You are right, and this is what happening at vortex reader module.

> So, if this is the case, vortex_channel_set_serialize() should be
> removed entirely from the API and ANS frames should always be received
> in order.

I don't think so. While vortex reader ensures protocol ordering, once it
finish and pass the frame to frame receive notification, threading
starts and, at this point, you may or may not care about reply
ordering. 

In fact, vortex_channel_set_serialize only applies to make ordered frame
handler activation rather message ordering. 

An alternative is to reduce the number of threads running in your
process to 1. No threads no race condition. See
vortex_thread_pool_set_num.

> As always, thanks for the hard work!

Thanks Chris. Cheers!

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