… | |
… | |
66 | |
66 | |
67 | The next sections will explain the API of L<AnyEvent::MP> by going through |
67 | The next sections will explain the API of L<AnyEvent::MP> by going through |
68 | a few simple examples. Later some more complex idioms are introduced, |
68 | a few simple examples. Later some more complex idioms are introduced, |
69 | which are hopefully useful to solve some real world problems. |
69 | which are hopefully useful to solve some real world problems. |
70 | |
70 | |
71 | =head1 Passing Your First Message |
71 | =head2 Passing Your First Message |
72 | |
72 | |
73 | As a start lets have a look at the messaging API. The following example |
73 | As a start lets have a look at the messaging API. The following example |
74 | is just a demo to show the basic elements of message passing with |
74 | is just a demo to show the basic elements of message passing with |
75 | L<AnyEvent::MP>. |
75 | L<AnyEvent::MP>. |
76 | |
76 | |
… | |
… | |
133 | |
133 | |
134 | Passing messages inside just one process is boring. Before we can move on |
134 | Passing messages inside just one process is boring. Before we can move on |
135 | and do interprocess message passing we first have to make sure some things |
135 | and do interprocess message passing we first have to make sure some things |
136 | have been set up correctly for our nodes to talk to each other. |
136 | have been set up correctly for our nodes to talk to each other. |
137 | |
137 | |
138 | =head1 System Requirements and System Setup |
138 | =head2 System Requirements and System Setup |
139 | |
139 | |
140 | Before we can start with real IPC we have to make sure some things work on |
140 | Before we can start with real IPC we have to make sure some things work on |
141 | your system. |
141 | your system. |
142 | |
142 | |
143 | First we have to setup a I<shared secret>: for two L<AnyEvent::MP> |
143 | First we have to setup a I<shared secret>: for two L<AnyEvent::MP> |
… | |
… | |
899 | |
899 | |
900 | warn "server ready.\n"; |
900 | warn "server ready.\n"; |
901 | |
901 | |
902 | AnyEvent->condvar->recv; |
902 | AnyEvent->condvar->recv; |
903 | |
903 | |
904 | It starts not much different, except that this time, we register the node |
904 | It starts out not much different then the previous example, except that |
905 | port and not any special port - the clients only want to know which node |
905 | this time, we register the node port in the global group and not any port |
906 | the server should be running, and in fact, they could also sue some kind |
906 | we created - the clients only want to know which node the server should be |
907 | of election mechanism or similar. |
907 | running on. In fact, they could also use some kind of election mechanism, |
|
|
908 | to find the node with lowest load or something like that. |
908 | |
909 | |
909 | The interesting change is that no port is created - the server is all |
910 | The more interesting change is that indeed no server port is created - |
910 | code, and does nothing. All it does is define a function C<client_connect> |
911 | the server consists only of code, and "does" nothing by itself. All it |
911 | that expects a client port and a nick as arguments. It then monitors the |
912 | does is define a function C<client_connect>, which expects a client port |
912 | client port and binds a receive callback on C<$SELF> that expects messages |
913 | and a nick name as arguments. It then monitors the client port and binds |
|
|
914 | a receive callback on C<$SELF>, which expects messages that in turn are |
913 | to broadcast to all clients. |
915 | broadcast to all clients. |
914 | |
916 | |
915 | The two C<mon> calls are a bit tricky - the first C<mon> is a shorthand |
917 | The two C<mon> calls are a bit tricky - the first C<mon> is a shorthand |
916 | for C<mon $client, $SELF>. The second does the normal "client has gone |
918 | for C<mon $client, $SELF>. The second does the normal "client has gone |
917 | away" clean-up action. Both could actually be rolled into one C<mon> |
919 | away" clean-up action. Both could actually be rolled into one C<mon> |
918 | action. |
920 | action. |
919 | |
921 | |
920 | C<$SELF> is a good hint that something interetsing is going on. And |
922 | C<$SELF> is a good hint that something interesting is going on. And |
921 | indeed, when looking at the client, there is a new function, C<spawn>: |
923 | indeed, when looking at the client code, there is a new function, |
|
|
924 | C<spawn>: |
922 | |
925 | |
923 | use common::sense; |
926 | use common::sense; |
924 | use AnyEvent::MP; |
927 | use AnyEvent::MP; |
925 | use AnyEvent::MP::Global; |
928 | use AnyEvent::MP::Global; |
926 | |
929 | |
… | |
… | |
961 | |
964 | |
962 | print "> "; |
965 | print "> "; |
963 | AnyEvent->condvar->recv; |
966 | AnyEvent->condvar->recv; |
964 | |
967 | |
965 | The client is quite similar to the previous one, but instead of contacting |
968 | The client is quite similar to the previous one, but instead of contacting |
966 | the server port (which no longer exists), it C<spawn>s a new port on the |
969 | the server I<port> (which no longer exists), it C<spawn>s (creates) a new |
967 | server I<node>: |
970 | the server I<port on node>: |
968 | |
971 | |
969 | $server = spawn $servernodes->[0], "::client_connect", $client, $nick; |
972 | $server = spawn $servernodes->[0], "::client_connect", $client, $nick; |
970 | mon $server, $client; |
973 | mon $server, $client; |
971 | |
974 | |
972 | And of course immediately monitors it. The C<spawn> function creates a new |
975 | And of course the first thing after creating it is monitoring it. |
973 | port on a remote node and returns its port ID. After creating the port it |
|
|
974 | calls a function on the remote node, passing any remaining arguments to |
|
|
975 | it, and - most importantly - within the context of the new port. The init |
|
|
976 | function can reside in a module (actually it normally I<should> reside |
|
|
977 | in a module) - AnyEvent::MP will automatically load the module if the |
|
|
978 | function isn't defined. |
|
|
979 | |
976 | |
|
|
977 | The C<spawn> function creates a new port on a remote node and returns |
|
|
978 | its port ID. After creating the port it calls a function on the remote |
|
|
979 | node, passing any remaining arguments to it, and - most importantly - |
|
|
980 | executes the function within the context of the new port, so it can be |
|
|
981 | manipulated by refering to C<$SELF>. The init function can reside in a |
|
|
982 | module (actually it normally I<should> reside in a module) - AnyEvent::MP |
|
|
983 | will automatically load the module if the function isn't defined. |
|
|
984 | |
980 | The C<spawn> function returns immediately, which means you can immediately |
985 | The C<spawn> function returns immediately, which means you can instantly |
981 | send messages to the port, long before the remote node has even heard |
986 | send messages to the port, long before the remote node has even heard |
982 | of our request to create a port on it. In fact, the remote node might |
987 | of our request to create a port on it. In fact, the remote node might |
983 | not even be running. Despite these troubling facts, everything should |
988 | not even be running. Despite these troubling facts, everything should |
984 | work just fine: if the node isn't running (or the init function throws an |
989 | work just fine: if the node isn't running (or the init function throws an |
985 | exception), then the monitor will trigger because the port doesn't exist. |
990 | exception), then the monitor will trigger because the port doesn't exist. |
986 | |
991 | |
987 | If the spawn message gets delivered, but the monitoring message is not |
992 | If the spawn message gets delivered, but the monitoring message is not |
988 | because of network problems (monitoring, after all, is implemented by |
993 | because of network problems (extremely unlikely, but monitoring, after |
989 | passing a message, and messages can get lost), then this connection loss |
994 | all, is implemented by passing a message, and messages can get lost), then |
990 | will eventually trigger the monitoring action. On the remote node (which |
995 | this connection loss will eventually trigger the monitoring action. On the |
991 | reciprocally monitors the client) the port will also be cleaned up on |
996 | remote node (which in return monitors the client) the port will also be |
992 | connection loss. When the node comes up and our monitoring message can be |
997 | cleaned up on connection loss. When the remote node comes up again and our |
993 | delivered it will instantly fail because the port has been cleaned up in |
998 | monitoring message can be delivered, it will instantly fail because the |
994 | the meantime. |
999 | port has been cleaned up in the meantime. |
995 | |
1000 | |
996 | If your head is spinning by now, that's fine - just keep in mind, after |
1001 | If your head is spinning by now, that's fine - just keep in mind, after |
997 | creating a port, monitor "the other side" from it, and all will be cleaned |
1002 | creating a port, monitor it on the local node, and monitor "the other |
998 | up just fine. |
1003 | side" from the remote node, and all will be cleaned up just fine. |
999 | |
1004 | |
1000 | =head2 Services |
1005 | =head2 Services |
1001 | |
1006 | |
1002 | Above it was mentioned that C<spawn> automatically loads modules, and this |
1007 | Above it was mentioned that C<spawn> automatically loads modules, and this |
1003 | can be exploited in various ways. |
1008 | can be exploited in various ways. |
… | |
… | |
1015 | AnyEvent::MP::Global), then you can configure this service statically: |
1020 | AnyEvent::MP::Global), then you can configure this service statically: |
1016 | |
1021 | |
1017 | aemp profile mysrvnode services mymod::service:: |
1022 | aemp profile mysrvnode services mymod::service:: |
1018 | aemp run profile mysrvnode |
1023 | aemp run profile mysrvnode |
1019 | |
1024 | |
1020 | And the module will automatically be started in the node, as specifying a |
1025 | And the module will automatically be loaded in the node, as specifying a |
1021 | module name (with C<::>-suffix) will simply load the module, which is then |
1026 | module name (with C<::>-suffix) will simply load the module, which is then |
1022 | free to do whatever it wants. |
1027 | free to do whatever it wants. |
1023 | |
1028 | |
1024 | Of course, you can also do it in the much more standard way by writing |
1029 | Of course, you can also do it in the much more standard way by writing |
1025 | a module (e.g. C<BK::Backend::IRC>), installing it as part of a module |
1030 | a module (e.g. C<BK::Backend::IRC>), installing it as part of a module |
1026 | distribution and then configure nodes, for example, if I want to run the |
1031 | distribution and then configure nodes, for example, if I want to run the |
1027 | Bummskraut IRC backend on a machine named "ruth", I could do this: |
1032 | Bummskraut IRC backend on a machine named "ruth", I could do this: |
1028 | |
1033 | |
1029 | aemp profile ruth addservice BK::Backend::IRC:: |
1034 | aemp profile ruth addservice BK::Backend::IRC:: |
1030 | |
1035 | |
1031 | And any F<aemp run> on that host will automaticlaly have the bummskraut |
1036 | And any F<aemp run> on that host will automaticllay have the bummskraut |
1032 | irc backend running. |
1037 | irc backend running. |
1033 | |
1038 | |
1034 | That's plenty of possibilities you can use - it's all up to you how you |
1039 | That's plenty of possibilities you can use - it's all up to you how you |
1035 | structure your application. |
1040 | structure your application. |
1036 | |
1041 | |