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
spawn-process presently (1) creates a process object and (2) registers it in the dereferencing table. This is a bit shy of what "spawn" means in other actor frameworks, where the generated process then automatically starts executing—in aether, one is expected to wrap spawn-process in future, otherwise the object doesn't get inserted in the simulation and passes to the garbage collector.
This is consistent with aether's style, but inconsistent with the general understanding of "spawn" and probably a source of bugs because of that. I don't think spawn-process is often used outside of d-p-u, in which case it could be rewritten as a d-p-u macro which includes the call to future, and the registration function could be separately exposed for the few times it is used. What I'm sure I don't want is for spawn-process to mean two different things in two different contexts. It would be unacceptable for it to need to be wrapped in future outside of d-p-u and to have future automatically injected in d-p-u.
The text was updated successfully, but these errors were encountered:
spawn-process
presently (1) creates a process object and (2) registers it in the dereferencing table. This is a bit shy of what "spawn" means in other actor frameworks, where the generated process then automatically starts executing—in aether, one is expected to wrapspawn-process
infuture
, otherwise the object doesn't get inserted in the simulation and passes to the garbage collector.This is consistent with aether's style, but inconsistent with the general understanding of "spawn" and probably a source of bugs because of that. I don't think
spawn-process
is often used outside ofd-p-u
, in which case it could be rewritten as ad-p-u
macro which includes the call tofuture
, and the registration function could be separately exposed for the few times it is used. What I'm sure I don't want is forspawn-process
to mean two different things in two different contexts. It would be unacceptable for it to need to be wrapped infuture
outside ofd-p-u
and to havefuture
automatically injected ind-p-u
.The text was updated successfully, but these errors were encountered: