You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use case is two sides of a connection where the parsing results from one side determine how the other side should proceed (e.g., STARTTLS by the client needs to be acked by the server before the TLS actually kicks in). Currently one needs to manually buffer any further data until the information about how to proceed becomes available, which is both very cumbersome and inefficient. The current thought is to introduce a semaphore-like mechanism that allows one side to wait for the other, yielding in the meantime. Details to be figured out.
The text was updated successfully, but these errors were encountered:
I'm thinking to introduce the concept of a barrier to the Spicy language: a mechanism to block processing until multiple parsers have all arrived at a certain point. barrier would be a new type, and one could maintain an instance inside the current %context to synchronize the two sides of a connection. Quick straw man of the type:
Constructor:
barrier(n: uint64): Constructor creating a barrier synchronizing a given number of parties.
Methods:
barrier.wait(): Block until the expected number of parties have arrived at the barrier.
barrier.arrive(): Signal a party's arrival at the barrier.
barrier.arrive_and_wait(): First arrive(), then wait().
barrier.abort(): Signal failure to all waiters (current and future); this would trigger a BarrierBroken exception to all waiting parties.
When a barrier destructs, all currently still waiting parties would receive a BarrierTimeout exception.
In a %context type, this could be use like this:
type Context = struct {
tls_handshake_done: barrier(2);
};
Use case is two sides of a connection where the parsing results from one side determine how the other side should proceed (e.g.,
STARTTLS
by the client needs to be acked by the server before the TLS actually kicks in). Currently one needs to manually buffer any further data until the information about how to proceed becomes available, which is both very cumbersome and inefficient. The current thought is to introduce a semaphore-like mechanism that allows one side to wait for the other, yielding in the meantime. Details to be figured out.The text was updated successfully, but these errors were encountered: