Closed HadrienG2 closed 8 years ago
Come to think of it, another issue is that this primitive has become more than a mere event from the moment where support for edge cases like cancellation or error handling were added.
At this point, it is more of a general interface to some procedural asynchronous operation, which may be a job or something else like IO. So we may want to call it "Operation" or something similar.
After playing with it a bit, "Operation" is not the right term, because "composing operations" will not mean what the user think it means. Back to the drawing board!
I the end, I went with "Outcome" for the actual synchronization primitive, together with the additional concept of "asynchronous operation" in the documentation.
Following the naming convention of OpenCL, the main inter-job synchronization primitive of this library, which is about notifying a job that another job has completed and thusly ordering operations, is called an Event.
One area where we may want to be careful, though, is that "event" has many meanings in concurrent programming. In particular, it can also mean a reusable software interrupt, acting as a notification of some reproducible action. For example, GUI controls trigger the same "event" whenever actuated, and file notification systems trigger a certain "event" whenever a file is modified.
Handling this kind of event is more complex and not usually needed in computational scenarios, which is why I refrained from doing it in this initial code. But I should not prevent it in the future by using a naming convention that considers job completion as the Only True Kind of event.
Thus, I would suggest renaming the current events to completion events, and leaving room for other events in the future, by moving to the following package hierarchy:
|- Phalanstery.Events (leaves room for top-level, general event concepts) +-- Phalanstery.Events.Completions (content of the former "Events" package)