Skip to content
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

Concurrent Actor Model #4

Open
PythonLinks opened this issue Mar 30, 2018 · 2 comments
Open

Concurrent Actor Model #4

PythonLinks opened this issue Mar 30, 2018 · 2 comments

Comments

@PythonLinks
Copy link

I want to build a real time server. Actually a tree of chat servers organized by topic. You can see the related lightening talk at blog.pythonlinks.info.
Erlang has the right concurrency model, but the language is not object-oriented.
Python has a great object language but only a single thread at a time.
Go is statically bound. Which brought me back to my beloved Objective-C.

But what to do about concurrency? I found the answer right here.
https://www.ios-blog.com/tutorials/objective-c/asynchronous-message-passing-with-actors-in-objective-c/

Basically every concurrent actor is a subclass of Thread. You send a message to the actor, it goes into their input queue. It gets copied and processed. No problem with locks. A very simple computational model. But the repository is not very active because with Apple’s Objective-C you have to create a new class for
every message. With Mulle-objc, the messages is itself a data structure, so easy to write a function which copies any message.

Anyhow I am new to all of this concurrency stuff. Am I on the right track? Is anyone else thinking along these lines? Is this the killer application for Mulle-objc?

Warm
Regards

Christopher Lozinski
PythonLinks.info

@mulle-nat
Copy link
Member

Actors are interesting, but I only have knowledge about them by having watched some Youtube videos :) I think the main difference between ObjC messages and Actor messages are, that Actor messages are one-way only (async), whereas ObjC is call and return (sync). So it looks more like an event model. I think for a distributed chat server this would be interesting to use, but I am out of my level of expertise there.

@PythonLinks
Copy link
Author

Thank you. Very good point. Messages to a thread would have to not return a value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants