Event queue

[paulidale]

Partial implementation of an event queue on top of #18274
This should be enough to get a feel for the design

• documentation is added or updated
• tests are added or updated

[mattcaswell]

Conspicuous by their absence are event queue tests

[mattcaswell]

This makes me wonder why we need non-dynamic events.

[paulidale]

A non-dynamic event can be embedded into another structure. i.e. cuts overhead allocating and freeing.
E.g. a re-transmit timer event will always exist with a connection -- do we need to allocate it separately?

Dropping non-dynamic is possible, but it feels like it will be useful.

[paulidale]

I didn't do tests because there is no guarantee that this approach will be used.

It definitely isn't quite ready to go at this point.

[t8m]

I liked the Richard's suggestion from our discussion that a type might have an inherent priority and we would not need a separate priority value.

[t8m]

A few more comments:

I suppose the events will be sorted by when as the primary key and priority as the secondary key in the priority queue. In that case I wonder how dispatch will work if some high priority event has when in the past but there are multiple lower priority events which have when even further in the past. I suppose these will be dispatched first which is not necessarily correct.

My another concern is with the subscription concept - I wonder whether this isn't overcomplicating things, in a way that requires complicated setup of the subscriptions. Couldn't we have for example a simple static per-type callback table? I mean the callback data and the context should provide enough contextual data. Do we think we will have multiple subscribers for each event type?

[paulidale]

@t8m, good points.

For dispatch point, it would be possible to extract a list of events that need to run now and sort them by priority rather than time. The main list would be sorted by time only and immediate events would go into the second queue only.

I'm sure about the subscriptions either. There are multiple options (in rough order of complexity):

• one event handler that dispatches by type -- this is kind of what @levitte did.
• a global array of static event handlers.
• a per SSL_METHOD array of static event handlers.
• installed per type handlers as per this.
• Event handler associated with the OSSL_EVENT object (caller sets what deals with the event).

They should all be fairly easy to convert between, e.g. the SSL_METHOD could install the per type handlers during initialisation or a single global event hander could dispatch by type to SSL_METHOD handlers.

[paulidale]

Embeddable or not?

The reasons for making the event structure embeddable is efficiency. I see two primary use cases:

• embedded in the caller's event context (the event lives with the event's data)

struct {
    // my fields
    ...
    // event
    OSSL_EVENT event;
} mydata;

ossl_event_queue_add(queue, &mydata->event);

• embedded with the protocol structure (e.g. re-transmit events)
  Plus a reduction in the number of malloc and free calls.

The reasons against are modularity and good coding practices.

Is this a premature optimisation?

[levitte]

• one event handler that dispatches by type -- this is kind of what @levitte did.

Uhm no. My design allowed multiple subscribers per event type. This was meant to allow a fork where needed...
for example, each stream could be handled by a separate subscriber, where the stream is identified by the indentifiers material attached to the event. With all those subscribers associated with the same queue, I imagine that whatever code that parsed a frame and found the identifying material as well as the payload, would generate one READ event and add it to the queue, and the rest would be a dispatch.

[t8m]

Embeddable or not?

I like the concept of embeddable events as I strongly suspect that for reasonable performance the library should avoid mallocs whenever possible. Retrofitting them into the design later when we'll find that the performance is sub-par might be quite a complicated effort.

IMO the biggest concern with embeddable events is the embedded event lifetime - i.e., how to ensure the enclosing object is not prematurely freed, or that the event is forcibly removed from the queue when freeing the enclosing object.

[t8m]

• a per SSL_METHOD array of static event handlers.

I think this should be sufficient for our needs. Unless we want to have some user-supplied callbacks directly used as event handlers for some event types. However I am not sure we need this as the callback(s) can be invoked from the static event handler instead.

IMO refactoring the dispatch if we find out that we really need multiple handlers per event type should not be too big effort.

[hlandau]

Looks good on the whole.

[hlandau]

I do think we can combine type and priority, and just call it type.

[paulidale]

I'm quite hesitant here. Keeping them distinct adds quite an amount of flexibility.

[paulidale]

It's tempting to remove type altogether since it's not something the event queue actually cares about anymore.