-
Notifications
You must be signed in to change notification settings - Fork 2
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
CQueue
: rework implementation
#11
Comments
Note, making this The rationale: a The way this could be implemented (though to be validated/discussed/...) is by running a first transaction in |
It's likely a good idea to model the implementation using DejaFu or IOSim and have tests in place to validate the properties we expect the implementation to adhere to. See also #17. |
This patch simplifies the `receive*` machinery, introducing an `after` `Match` which uses STM's `registerDelay` to implement a `receive` with timeouts, instead of relying on `CQueue`s `Timeout` and `NonBlocking` implementations. This should ease reworking `CQueue`, since there should be no need for a distinction between blocking, timeout and non-blocking behaviour in its implementation. Hence, from now on, `troupe` only uses `CQueue`s `Blocking` `dequeue` method. See: #12 See: #11
This patch simplifies the `receive*` machinery, introducing an `after` `Match` which uses STM's `registerDelay` to implement a `receive` with timeouts, instead of relying on `CQueue`s `Timeout` and `NonBlocking` implementations. This should ease reworking `CQueue`, since there should be no need for a distinction between blocking, timeout and non-blocking behaviour in its implementation. Hence, from now on, `troupe` only uses `CQueue`s `Blocking` `dequeue` method. See: #12 See: #11
This patch simplifies the `receive*` machinery, introducing an `after` `Match` which uses STM's `registerDelay` to implement a `receive` with timeouts, instead of relying on `CQueue`s `Timeout` and `NonBlocking` implementations. This should ease reworking `CQueue`, since there should be no need for a distinction between blocking, timeout and non-blocking behaviour in its implementation. Hence, from now on, `troupe` only uses `CQueue`s `Blocking` `dequeue` method. See: #12 See: #11
This patch simplifies the `receive*` machinery, introducing an `after` `Match` which uses STM's `registerDelay` to implement a `receive` with timeouts, instead of relying on `CQueue`s `Timeout` and `NonBlocking` implementations. This should ease reworking `CQueue`, since there should be no need for a distinction between blocking, timeout and non-blocking behaviour in its implementation. Hence, from now on, `troupe` only uses `CQueue`s `Blocking` `dequeue` method. See: #12 See: #11
This patch simplifies the `receive*` machinery, introducing an `after` `Match` which uses STM's `registerDelay` to implement a `receive` with timeouts, instead of relying on `CQueue`s `Timeout` and `NonBlocking` implementations. This should ease reworking `CQueue`, since there should be no need for a distinction between blocking, timeout and non-blocking behaviour in its implementation. Hence, from now on, `troupe` only uses `CQueue`s `Blocking` `dequeue` method. See: #12 See: #11
The current implementation of
CQueue
is quite complicated. Reworking this, simplifying it, potentially making it fully STM-only, could be useful.See: #7
The text was updated successfully, but these errors were encountered: