Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a mechanism to synchronize two parse streams #1328

Open
rsmmr opened this issue Dec 13, 2022 · 2 comments · May be fixed by #1373
Open

Provide a mechanism to synchronize two parse streams #1328

rsmmr opened this issue Dec 13, 2022 · 2 comments · May be fixed by #1373
Assignees
Labels
Feature Request Request for new functionality

Comments

@rsmmr
Copy link
Member

rsmmr commented Dec 13, 2022

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.

@rsmmr
Copy link
Member Author

rsmmr commented Feb 7, 2023

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);
};

@rsmmr rsmmr self-assigned this Feb 9, 2023
@rsmmr rsmmr linked a pull request Feb 10, 2023 that will close this issue
@zeek-bot
Copy link

zeek-bot commented Sep 5, 2023

This issue has been mentioned on Zeek. There might be relevant details there:

https://community.zeek.org/t/need-help-for-spicy-analyzer/7126/2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Request for new functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants