| Overview |  |
Copyright © 2021 Marc Worrell
Behaviours: gen_server.
Authors: Marc Worrell (marc@worrell.nl).
| code_change/3 | |
| handle_call/3 | |
| handle_cast/2 | |
| handle_info/2 | |
| init/1 | |
| process_pid/1 | Find the process pid for the process owning the ets table. |
| read/1 | Read a payload from the buffer. |
| start_link/2 | Create a new process managing a ringbuffer. |
| terminate/2 | |
| write/2 | Write a payload the buffer. |
code_change(OldVsn, State, Extra) -> any()
handle_call(X1, From, State) -> any()
handle_cast(Msg, State) -> any()
handle_info(Info, State) -> any()
init(X1) -> any()
process_pid(Name::atom()) -> {ok, pid()} | {error, badarg}
Find the process pid for the process owning the ets table. If the buffer does not exist then an error is returned.
read(Name::atom()) -> {ok, {Skipped::pos_integer(), Payload::term()}} | {error, empty}
Read a payload from the buffer. Skip entries that are deleted by the writers.
There are a coupe of race conditions we need to take care of:
1. Writer incremented -> Reader tries entry --> Writer writes entry In this case the w-value read by the reader is Size smaller than that of the writer. In this case we wait till the writer finishes writing.
2. Two or more readers arrive at the same time, incrementing the reader value. One of the readers will have the correct value and can fetch the next entry. In this case the reader can move past the writer if there are not enough entries in the buffer for all readers.
For the case where multiple readers are racing past the writer can not be solved without synchronization, we let the ringbuffer process handle the reader increment.start_link(Name::atom(), Size::pos_integer()) -> {ok, pid()} | {error, term()}
Create a new process managing a ringbuffer.
terminate(Reason, State) -> any()
write(Name::atom(), Payload::term()) -> ok
Write a payload the buffer. If the readers can't keep up then older entries are deleted.
Generated by EDoc