Distribute Processing
Volume Number: 8
Issue Number: 2
Column Tag: Jörg's Folder
Related Info: Apple Event Mgr
A Way to Distribute Processing
With today’s Apple Event technology, you could set up a distributed
processor
By Jörg Langowski, MacTutor Regular Contributing Author
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
The example that I presented last month showed a very simple way to
communicate between Fortran programs using the built-in Apple event handling of the
Language Systems (LS) Fortran runtime system. Although the F_SendEvent routine can
be used to send high-level events of class 'aevt' in a very simple way, its possibilities
are limited. The event class can not be changed, and therefore you cannot declare your
own suite of events with a new class identifier. Also, the only kind of parameter that
you can add to an Apple event that you send with F_SendEvent is a filename, which
identifies a file to be associated with the Apple event. This makes sense when you want
to send an 'odoc' or 'pdoc' event, but the file remains the only way to send data with the
Apple event.
On the other hand, the LS Fortran runtime system has Apple event handling built
in, so you don’t have to take care to make the main event loop System 7-aware. This is
the great advantage of LS Fortran when you are porting programs from other machines,
and nevertheless want to add easily some System 7 goodies. Exchange of arbitrary types
of data between programs on the same machine or over a network is certainly one of the
more important features of System 7. So this time, I’ll show you how to create and send
an arbitrary Apple event in LS Fortran. The event can contain data that will be
processed by the receiving program and sent back when it’s done.
A math library server
When you look at a large computer installation with many workstations and
mainframes coupled together through a network, you can’t avoid the impression that
most of the time the workstations - at least when its users are engaged in
non-productive activities such as sleeping, eating, editing programs or writing
manuscripts - are doing nothing but sit there and wait for something to happen. The idle
CPU time that accumulates in a place where tens or even hundreds of MacII - class
machines are kept must be enormous. Why couldn’t that idle time be used by other
machines to do CPU-intensive things like operations on large matrices? Even if any
single node on the network is not any more powerful than the machine that needs the
extra CPU power, one could split up operations into blocks that would be executed by
different idle nodes on the network.
You can imagine the implications of such a system: for instance, a small process
turning in the background of each MacII on the network and implementing, for example,
the Linpack math library. The process would accept requests from other nodes for
calculating matrix operations, do the calculations only during the time when really
nothing else is happening (the user at the node should always have priority), and send
the result back to the requesting node.
The CPU-intensive program that is executing on one node is responsible for
splitting its operations into pieces that can be executed independently, sending out the
requests for calculations, and reassembling the answers into one final result.
In this column, I won’t show you all the pieces that are necessary for building
such a system - this would much exceed the scope of this column, and anyway, if I had
everything done perfectly, I’d sell it and make lots of money. But we can look at a very
simple example: a “server process” that accepts an array of real numbers, squares
every element and sends back the resulting array, and a program that requests this
service.
Setting up an Apple Event and sending it
We’ll define the Apple event first in which we are going to encapsulate our data.
Let’s give it the class 'JLMT', and ID 'MULT' (why not). Certain data is always
associated with any apple event: a target address descriptor that specifies where the
event is going to be sent, a return ID that can be used by a program that sent several
Apple events to find out who sent the reply, and a transaction ID. In addition, if you want
to send data with the event, you have to add descriptors to it that specify that data.
In the example given below the setting up and sending of the event are done by the
routine send_array. First of all, PPCBrowser is called to select the process to which we
send the event (this is the routine that displays the dialog “Please select a program to
link to:”). The information returned by PPCBrowser is then put into a target address
descriptor which we created with AECreateDesc. We need this target address descriptor
for creating the actual Apple event with AECreateAppleEvent. The other parameters
after the event class, ID, and the target address are the return ID (here we specify that
a unique return ID is generated automatically) and a transaction ID (the parameter
kAnyTransactionID means that the event does not belong to any particular group of
events which form a separate transaction).
After the Apple event is created, we can add data to it. We’ll add three
parameters: the x and y dimensions of a 2-dimensional array, both 32-bit integers
(type 'long'), and the array data itself, which is sent as an unformatted string of bytes
(type 'text'). The array is actually of type real*4, but since only the length (in bytes)
and pointer to the first element are required, we can use the 'text' type in the Apple
event. The three parameters will also get names ('XDIM','YDIM' and 'ARRY') to identify
them uniquely.
Having set up the Apple event, we can then send it to the process which does the
calculation. On sending (with the AESend routine) we specify the address of the Apple
event that we want to send (normal), a pointer to a reply Apple event structure where
the reply will be received, and a parameter that specifies that we wish a reply that
will be received through the normal event queue (kAEQueueReply), and that the
receiving program doesn’t need to notify the user that the event was received
(kAENeverInteract). We might also have specified kAEWaitReply here, in that case, the
sending program would idle and yield the CPU to other programs on the same machine
until the reply was received. Since we are planning to send out several Apple events to
different processes for parallel processing without having to wait for a reply each
time, we use the queue reply mode.
After sending the Apple event, send_array returns to the Fortran
runtime system.
The server process
The Apple event is received by the second program in the example. The main
program simply installs a handler for the JLMT / MULT Apple event (the routine
get_array) and then drops into an idle loop. The Fortran output window is never
activated.
The event handler will receive the Apple event and a pointer to a reply event. It
extracts the data out of the received event, processed it and puts it into the reply, which
is automagically sent back by the Apple event manager. Extracting parameters is done
by the AEGetParamPtr routine, where you have to specify the address of the Apple event
(of course), and the identifier and type of the parameter to extracted. You also have to
provide a pointer to a space where the data can be stored. The routine returns the
parameter, or an error if such a parameter does not exist.
Thus, we extract the x and y dimensions of the array into two 32 bit integers,
calculate the array size, and extract the array data into a real*4 array. We then call
the process_array routine, which squares every element and divides it by 10000, and
then put the three parameters XDIM, YDIM and ARRY into the reply Apple event record
using the routine AEPutParamPtr which is very analogous to AEGetParamPtr. When our
event handler returns, the Apple event manager will send the reply Apple event back to
the program that sent the original event.
Receiving the result
The reply event is of class 'aevt', ID 'ansr'. Since the main program called
AESend with the kAEQueueReply parameter, we will receive the reply through the
normal event loop. Therefore, we must install our own handler for a reply event, in our
case the routine get_reply. In this routine we extract the XDIM, YDIM and ARRY
parameters out of the reply, write a message to the output window that the reply was
received and return. The processed array data can then be displayed with the
show_array routine which is selected from a menu.
[I have forgotten to mention the array setup routine, also selected from a menu,
which puts the initial data into the array, and the menu selection send array, which
calls the send_array routine. You’ll already have discovered them.]
What is missing?
Of course, this example is far from the idea of the math routine server that I
mentioned initially. Several things would have to be added to make distributed
processing really work: First of all, all replies will have the same class and ID
('aevt'/'ansr'), and since you might have sent out several requests for calculations, you
have to remember the question when you are getting an answer. This is what the return
ID is good for -- by keeping a table of pending requests and their return IDs, a reply
can be easily identified. Implementation is left as an exercise for the reader, as is the
automatic identification and selection of available server processes on a large Appletalk
internetwork. Error handling, too, is very rudimentary in the example; in practice,
the program would have to be stable against wrong parameters, values out of range,
missing parameters, and send back error messages with some meaningful content.
Anyway, I hope this example has given you an impression about the many things
that can be done with Apple events. See you next month with more interesting things
from the Fortran side and elsewhere.
Example: Distributed processing with Apple Events in LS Fortran
!!M Inlines.f
!!G AEvent.finc
c
c
program AEMenu
implicit none
external get_reply,send_array
integer*2 err
err = AEInstallEventHandler
(%val('aevt'),%val('ansr'),%val(%loc(get_reply)),
%val(int4(0)),%val(int2(0)))
if (err. ne. 0) then
type *,'Error installing Apple event, result code = ',err
end if
call AddMenuItem ('AE menu', 'setup array', setup_array)
call AddMenuItem ('AE menu', 'send array', send_array)
call AddMenuItem ('AE menu', 'show array', show_array)
end
subroutine setup_array
implicit none
real*4 myarray(10000)
integer xdim,ydim
global xdim,ydim,myarray
xdim = 10
ydim = 15
call setarray(myarray,xdim,ydim)
end
subroutine setarray(array,xdim,ydim)
integer xdim,ydim
real*4 array(xdim,ydim)
do i=1,xdim
do j=1,ydim
array(i,j) = 10000.*(i-1) + 1.*(j-1)
end do
end do
end
subroutine show_array
implicit none
real*4 myarray(10000)
integer xdim,ydim
global xdim,ydim,myarray
Referenced by (2):