optimize the message passing API for common use
2 views
Skip to first unread message
arschles
Apr 9, 2009, 1:16:15 AM4/9/09
to pysage
My apologies - I posted this as issue 4. It's late and I don't know
what I was thinking!
I like what pysage is trying to do because I view message passing
concurrency as the "right" way to do concurrency.
I have only had a brief look at pysage so forgive me if I'm ignorant
on the pysage API. It seems as if
the message passing API could be easier to use in the following way:
When you queue/send a message (ie: multicast or monocast), that
message currently is "deferred" sending until you call
ActorManager.tick. Instead (or as an addition), that message could be
asynchronously sent to the receiver(s). This possibility is further
detailed in http://code.google.com/p/pysage/issues/detail?id=3.
Having this ability to immediately send messages asynchronously
(instead of effectively
scheduling them for later, as pysage seems to have now) would more
closely approximate erlang
and some other message passing concurrency implementations (including
gears workerpools,
which is my favorite!)
Having this immediate send functionality could eliminate the need for
the ActorManager.tick
instance method, or pysage could have deferred messages which would be
sent later with tick.
Delete comment Comment 1 by arsch...@gmail.com, Today (12 minutes ago)
additionally, it would be great to have a convenience method in the
Actor that would allow clients to send raw
data (ie: strings, integral types, etc...) as messages. of course,
this method would package up this raw data into a proper message.
what does everyone else think?
what I was thinking!
I like what pysage is trying to do because I view message passing
concurrency as the "right" way to do concurrency.
I have only had a brief look at pysage so forgive me if I'm ignorant
on the pysage API. It seems as if
the message passing API could be easier to use in the following way:
When you queue/send a message (ie: multicast or monocast), that
message currently is "deferred" sending until you call
ActorManager.tick. Instead (or as an addition), that message could be
asynchronously sent to the receiver(s). This possibility is further
detailed in http://code.google.com/p/pysage/issues/detail?id=3.
Having this ability to immediately send messages asynchronously
(instead of effectively
scheduling them for later, as pysage seems to have now) would more
closely approximate erlang
and some other message passing concurrency implementations (including
gears workerpools,
which is my favorite!)
Having this immediate send functionality could eliminate the need for
the ActorManager.tick
instance method, or pysage could have deferred messages which would be
sent later with tick.
Delete comment Comment 1 by arsch...@gmail.com, Today (12 minutes ago)
additionally, it would be great to have a convenience method in the
Actor that would allow clients to send raw
data (ie: strings, integral types, etc...) as messages. of course,
this method would package up this raw data into a proper message.
what does everyone else think?
John Yang
Apr 9, 2009, 1:55:22 AM4/9/09
to pys...@googlegroups.com
arschles, welcome to the group. Effectively, "tick" was implemented
as the method you would call repeatedly in a game loop. It flushes
the queued up messages to the recipients. These messages may come
locally (local to the process), from another process (pysage group) or
from another network. "tick" polls for that data before it processes
them.
If I'm understanding correctly, the "immediate send" functionality is
the "trigger" method, which is currently implemented. It immediately
processes the message and blocks until the given message is processed.
Therefore, "trigger" is a synchronous call.
On the raw data suggestion, do you mean to provide functionality to
send a message without having to write the message class? That may be
nice, can you provide me more detail on this use case?
Thanks,
John S. Yang
as the method you would call repeatedly in a game loop. It flushes
the queued up messages to the recipients. These messages may come
locally (local to the process), from another process (pysage group) or
from another network. "tick" polls for that data before it processes
them.
If I'm understanding correctly, the "immediate send" functionality is
the "trigger" method, which is currently implemented. It immediately
processes the message and blocks until the given message is processed.
Therefore, "trigger" is a synchronous call.
On the raw data suggestion, do you mean to provide functionality to
send a message without having to write the message class? That may be
nice, can you provide me more detail on this use case?
Thanks,
John S. Yang
arschles
Apr 10, 2009, 12:00:24 AM4/10/09
to pysage
Thanks for the welcome. My "real job" is busy right now, but when I
get some time I'm going to hack on pysage a bit, if for no other
reason than to understand the codebase already.
As for the "immediate send" functionality:
it would be like "trigger" but asynchronous. If such functionality was
implemented in a method called ActorMgr.send_now, then calling
send_now would queue a message and return. However, there would be a
background thread/process (unseen to the caller) whose sole
responsibility is to dispatch that message. This way, any actor can
just queue a message and continue without worrying about flushing
messages (although your "game loop" explanation has made me understand
why that model is also needed). This "asynchronous send" functionality
is similar to that which Erlang provides (also the Gears workerpool),
and I bring it up because it makes more sense to me than the flushing
model that you described with tick.
As for the raw data functionality:
yes, I mean functionality to send a message without having to write a
message class. The best use case that I can think of is a single, "one-
off" message that an actor wants to send. In this case and other
similar cases, I think it's too much overhead to have to write a new
message class. Some great examples I can think of are notifications -
things like "message received", "computation done", etc...
Alternatively, I guess pysage could include some pre-fab message
classes to solve some of the most common use cases.
This functionality could be implemented as a wrapper on top of a
generic message class. This way any actor can be guaranteed to be able
to receive and understand any message regardless of whether it was
sent "ad-hoc" or via a structured message class.
Sorry for the long message. Maybe this thread should be forked?
Aaron
> > detailed inhttp://code.google.com/p/pysage/issues/detail?id=3.
get some time I'm going to hack on pysage a bit, if for no other
reason than to understand the codebase already.
As for the "immediate send" functionality:
it would be like "trigger" but asynchronous. If such functionality was
implemented in a method called ActorMgr.send_now, then calling
send_now would queue a message and return. However, there would be a
background thread/process (unseen to the caller) whose sole
responsibility is to dispatch that message. This way, any actor can
just queue a message and continue without worrying about flushing
messages (although your "game loop" explanation has made me understand
why that model is also needed). This "asynchronous send" functionality
is similar to that which Erlang provides (also the Gears workerpool),
and I bring it up because it makes more sense to me than the flushing
model that you described with tick.
As for the raw data functionality:
yes, I mean functionality to send a message without having to write a
message class. The best use case that I can think of is a single, "one-
off" message that an actor wants to send. In this case and other
similar cases, I think it's too much overhead to have to write a new
message class. Some great examples I can think of are notifications -
things like "message received", "computation done", etc...
Alternatively, I guess pysage could include some pre-fab message
classes to solve some of the most common use cases.
This functionality could be implemented as a wrapper on top of a
generic message class. This way any actor can be guaranteed to be able
to receive and understand any message regardless of whether it was
sent "ad-hoc" or via a structured message class.
Sorry for the long message. Maybe this thread should be forked?
Aaron
John Yang
Apr 10, 2009, 3:13:57 AM4/10/09
to pys...@googlegroups.com
On Thu, Apr 9, 2009 at 9:00 PM, arschles <arsc...@gmail.com> wrote:
>
> Thanks for the welcome. My "real job" is busy right now, but when I
> get some time I'm going to hack on pysage a bit, if for no other
> reason than to understand the codebase already.
Hack away!
>
> Thanks for the welcome. My "real job" is busy right now, but when I
> get some time I'm going to hack on pysage a bit, if for no other
> reason than to understand the codebase already.
>
> As for the "immediate send" functionality:
> it would be like "trigger" but asynchronous. If such functionality was
> implemented in a method called ActorMgr.send_now, then calling
> send_now would queue a message and return. However, there would be a
> background thread/process (unseen to the caller) whose sole
> responsibility is to dispatch that message. This way, any actor can
> just queue a message and continue without worrying about flushing
> messages (although your "game loop" explanation has made me understand
> why that model is also needed). This "asynchronous send" functionality
> is similar to that which Erlang provides (also the Gears workerpool),
> and I bring it up because it makes more sense to me than the flushing
> model that you described with tick.
"trigger" is only used for local messages. All inter-process messages
> As for the "immediate send" functionality:
> it would be like "trigger" but asynchronous. If such functionality was
> implemented in a method called ActorMgr.send_now, then calling
> send_now would queue a message and return. However, there would be a
> background thread/process (unseen to the caller) whose sole
> responsibility is to dispatch that message. This way, any actor can
> just queue a message and continue without worrying about flushing
> messages (although your "game loop" explanation has made me understand
> why that model is also needed). This "asynchronous send" functionality
> is similar to that which Erlang provides (also the Gears workerpool),
> and I bring it up because it makes more sense to me than the flushing
> model that you described with tick.
including network messages are currently sent immediately.
>
> As for the raw data functionality:
> yes, I mean functionality to send a message without having to write a
> message class. The best use case that I can think of is a single, "one-
> off" message that an actor wants to send. In this case and other
> similar cases, I think it's too much overhead to have to write a new
> message class. Some great examples I can think of are notifications -
> things like "message received", "computation done", etc...
need for it. Although I'm not sure about the best way to implement
this yet, given the "binary packing" constraint, for performance
reasons. We may need to declare a special packet id and have it
parsed differently.
>
> Alternatively, I guess pysage could include some pre-fab message
> classes to solve some of the most common use cases.
>
> This functionality could be implemented as a wrapper on top of a
> generic message class. This way any actor can be guaranteed to be able
> to receive and understand any message regardless of whether it was
> sent "ad-hoc" or via a structured message class.
>
> Sorry for the long message. Maybe this thread should be forked?
your reply.
arschles
Apr 11, 2009, 5:07:03 PM4/11/09
to pysage
started a new discussion for raw message functionality: (http://
groups.google.com/group/pysage/t/66e407b5586903f7)
On Apr 10, 12:13 am, John Yang <bigjh...@gmail.com> wrote:
groups.google.com/group/pysage/t/66e407b5586903f7)
On Apr 10, 12:13 am, John Yang <bigjh...@gmail.com> wrote:
Reply all
Reply to author
Forward
0 new messages