VortexEvent * vortex_pull_next_event ( VortexCtx ctx,
int  milliseconds_to_wait 

Allows to get next pending event.

The function will block the caller in the case no event is available.

ctxThe context with PULL API activated, where pending events will be checked.
milliseconds_to_waitHow many milliseconds to wait for an event before returning NULL. In the case 0 is used, the function will wait with no limit until next event.
A reference to the VortexEvent representing an async event received. According to the type returned by vortex_event_get_type, the event has particular data associated. See VortexEventType for more information. In the case a limited wait (milliseconds_to_wait) is configured, the function can return NULL, which means timeout reached.

After processing event returned, you must call to vortex_event_unref to release resources allocaetd by this event.

Note about events that are returned by this function:

Important note: don't assume a particular order for events pulled from the queue (this function).

The pull API is designed to serialize handler activations, queuing those events so the user can pull them via vortex_pull_next_event.

However, because those handler activations are run by threads, it may happen that the thread that should queue the VORTEX_EVENT_CONNECTION_CLOSED may be stopped (by the thread planner) giving priority to the thread that handles the VORTEX_EVENT_CHANNEL_CLOSE (even having that thread activated before VORTEX_EVENT_CONNECTION_CLOSED).

As a consequence, you may find events on the queue that aren't ordered in an expected way (especially for connection close because that activation runs on a separated thread, as oppose to other events that are run with threads from the pool).

References vortex_async_queue_pop(), vortex_async_queue_timedpop(), and vortex_ctx_get_data().