Actor Model OS
Posted: Fri Jan 18, 2008 2:06 pm
Hello,
lately I was wondering about "everything is a file" concept and if it would be possible to extend to "everything is an actor" metaphor. It seemed interesting because it possibly allows a more abstract and general abstraction (?). It also seems to suit well for an OS for concurrency.
However it seems that messages are passed to actors blindly (ie. anonymous messages). This prohibits an execution model similar to co-routines (where values are returned) and requires a more flexible continuation forwarding model. Are there design complexities or difficulties about adapting everything to such model?
Also, I assume it should be possible to nest actors. Having a file system of actors allow named addressing of the actors, possibly a standard interface and sand-boxing. However actor sharing could be difficult. Consider for example an actor "/dev/floppy", if a user logs in, it would be more secure to fork a new sand-boxed tree for the user, however how would he share the floppy? Would it be a symlink? Would it be a "portal" actor, redirecting messages? How secure would that be? Maybe it's more secure to have the parent actor tree have it's fork nested and probing for changes to store later.
Probing seems more secure, since the parent has control, however probing introduces overhead. For a tree actor model it would be nicer to have a floppy tree containing listener changes (ie. writes are forwarded to listeners). But again, because the listeners are contained in a forked tree it can't access the real floppy without a portal actor or parent probing.
Other problems arose in the idea. Files. How are files actors? The stub solution is to have a "view" message which receives an actor address to forward all of it's contents (or a range of it) and to have a "update" message which would be like a diff patch.
Another thought: if the actors are nested, wouldn't it be better to have child helper actors that receive specific messages. Then there's less message parsing overhead. Example: in the above file actor, it would have two children: file.view, file.update . Then the message would be simply the arguments.
One last thought: actor componentry. Perhaps it would be nice to have some atomic actors (if-then-else, screen.out, screen.pixels, keyboard, mouse, and basic datatypes and functions (like map, cat, cascade, list, node, timer, etc.) and build actors through wiring of these atomic actors. For speeds sake, a partial evaluated would compile the static parts.
As you can see, I quite like the idea, however I'm still struggling on an implementation plan, which is why I need all the feedback I can get. Thanks,
JVFF
lately I was wondering about "everything is a file" concept and if it would be possible to extend to "everything is an actor" metaphor. It seemed interesting because it possibly allows a more abstract and general abstraction (?). It also seems to suit well for an OS for concurrency.
However it seems that messages are passed to actors blindly (ie. anonymous messages). This prohibits an execution model similar to co-routines (where values are returned) and requires a more flexible continuation forwarding model. Are there design complexities or difficulties about adapting everything to such model?
Also, I assume it should be possible to nest actors. Having a file system of actors allow named addressing of the actors, possibly a standard interface and sand-boxing. However actor sharing could be difficult. Consider for example an actor "/dev/floppy", if a user logs in, it would be more secure to fork a new sand-boxed tree for the user, however how would he share the floppy? Would it be a symlink? Would it be a "portal" actor, redirecting messages? How secure would that be? Maybe it's more secure to have the parent actor tree have it's fork nested and probing for changes to store later.
Probing seems more secure, since the parent has control, however probing introduces overhead. For a tree actor model it would be nicer to have a floppy tree containing listener changes (ie. writes are forwarded to listeners). But again, because the listeners are contained in a forked tree it can't access the real floppy without a portal actor or parent probing.
Other problems arose in the idea. Files. How are files actors? The stub solution is to have a "view" message which receives an actor address to forward all of it's contents (or a range of it) and to have a "update" message which would be like a diff patch.
Another thought: if the actors are nested, wouldn't it be better to have child helper actors that receive specific messages. Then there's less message parsing overhead. Example: in the above file actor, it would have two children: file.view, file.update . Then the message would be simply the arguments.
One last thought: actor componentry. Perhaps it would be nice to have some atomic actors (if-then-else, screen.out, screen.pixels, keyboard, mouse, and basic datatypes and functions (like map, cat, cascade, list, node, timer, etc.) and build actors through wiring of these atomic actors. For speeds sake, a partial evaluated would compile the static parts.
As you can see, I quite like the idea, however I'm still struggling on an implementation plan, which is why I need all the feedback I can get. Thanks,
JVFF