[Impromptu] ipc calls

[David Smith]

IPC is Inter Process Connection?

Wow.   Does this mean if I had two or three (borrowed) laptops on  
wireless,
all running Impromptu, and I can spawn processes to the other computers?

And develop the whole thing (in a slow mode) on just one computer?

Dave





On Jan 2, 2010, at 10:17 PM, Andrew Sorensen wrote:

> Hi Chris and Co.
>
> Sorry this email has turned into a bit of a documentation exercise,  
> as I think processes in Impromptu are still a little misunderstood.
>
>>  callback seems like a misnomer because if i'm not mistaken,  
>> callback can be used to call any process,  not just the one that  
>> encapsulates it?
>
> Actually no, callback always calls the specified function in the  
> process that it was called in.   However, it is trivial to schedule  
> calls to other processes using a combination of callback and  
> Impromptu's IPC architecture.
>
> (callback (+ (now) *second*) '* 2 3)
> (callback (+ (now) *second*) 'ipc:call "utility process" '* 2 3)
>
> The first line calls (* 2 3) in one second in the current process  
> (whatever that is currently set to).  The second callback calls  
> (ipc:call "utility process" '* 2 3) in one second (in whatever the  
> current process is) - which then immediately calls (* 2 3) in the  
> "utility process" - always the "utility process" no matter what the  
> current process is set to.
>
> Of course you could easily tidy the call up with a macro.
>
> (define-macro (proc-cb . args)
>    `(callback ,(cadr args) 'ipc:call ,(car args) ,@(cddr args)))
>
> (proc-cb "utility process" (+ (now) *second*) '* 2 3)
>
> This makes it trivially easy to spawn work off onto other cores/ 
> hosts etc..  Here's an example of an alarm clock distributed over  
> four processes (note that these processes could potentially be  
> running remotely).
>
> ;; a distribued alarm clock
>
> ;; define four process names
> (define procs (list "proc one" "proc two" "proc three" "proc four"))
>
> ;; start four processes
> (dotimes (i 4)
>    (ipc:new-process (list-ref procs i) (+ 8990 i)))
>
> ;; define a worker function to set and call alarms in each of four  
> processes
> (dotimes (i 4)
>    (ipc:define (list-ref procs i) 'worker
>                (lambda (time)
>                   (print 'set-alarm-in-proc: (ipc:get-process-name)
>                          'for-time: (objc:date:make time))
>                   (sys:wait (clock->samples time))
>                   (print 'alarm: (ipc:get-process-name)
>                          'time: (objc:date:make (samples->clock  
> (now)))))))
>
>
> ;; start loop firing off alarm requests randomly to four processes
> (define loop
>    (lambda (beat)
>       (callback (*metro* beat) 'ipc:call (list-ref procs (random 4))
>                 'worker (+ (clock) (random 60)))
>       (callback (*metro* (+ beat (* 1/2 1))) 'loop (+ beat 1))))
>
> ;; start manager loop
> (loop (*metro* 'get-beat 4))
>
> This example is really all you need to understand how to do your  
> own load balancing, distributed computation etc..
>
> Just a note on remote vs local processes.  You spawn a new process  
> in impromptu by calling ipc:new-process.  This creates a new  
> impromptu process which you give a name to and then call using ipc  
> commands.  Remote processes work slightly differently because you  
> do not create them.  They already exist and you just connect to  
> them with an alias.  So for example.  Creating a process locally  
> works like this:
>
> (ipc:new-process "my-new-proc" 9287)
> (print 'result: (ipc:call "my-new-proc" '* 2 3))
>
>  If someone wanted to connect to this existing "my-new-proc"  
> process from another host they would do this:
>
> (ipc:connect-to-process "the-remote-proc" "varese.local" 9287)
> (ipc:call-async "the-remote-proc" 'print "hello world")
>
> The remote host can call the connection whatever they like, the  
> important details are the hostname and the port to connect to.  The  
> important thing to note is that they have not created a new process  
> on the host varese.local they have just connected an "alias" to an  
> existing process.
>
> One last thing in this ever expanding email.  In order to use  
> ipc:call (i.e. an ipc call that returns a value) from a remote  
> host, you need to supply an additional argument which is the  
> process name (as named by the remote host) to send the result to.   
> You don't need to supply this argument locally but you do need to  
> supply it remotely.  So here's a common example that connects to a  
> remote hosts "primary process" - by convention I usually prefix the  
> hosts name.
>
> ;; connecting from debussy.local to varese.local
> ;; first create alias to "primary process" on varese - called  
> "varese:primary process"
> (ipc:connect-to-process "varese:primary process" "varese.local" 7010)
> ;; secondly use the alias to establish another alias
> ;; going the other way - from varese back to debussy
> (ipc:call-async "varese:primary process" 'ipc:connect-to-process
>                 "debussy:primary process" "debussy.local" 7010)
> ;; now we can make synchronous calls from debussy to varese like this
> (print 'result: (ipc:call "varese:primary process" "debuss:primary  
> process" '* 2 3))
> ;; of course you can also spawn new processes remotely
> (ipc:call-async "varese:primary process" 'ipc:new-process "another- 
> new-proc" 9288)
> ;; and connect to them remotely with an alias
> (ipc:connect-to-process "varese:another-new-proc" "varese.local" 9288)
> ;; etc..
>
> Processes in Impromptu are quite powerful but are generally under- 
> utilised.  I expect that this is in part because I haven't document  
> them very well so please let me know if something is unclear.
>
> Cheers,
> Andrew.
>
>
>
>>
>> 2010/1/2 Andrew Brown <a.brown at qut.edu.au>
>> I think "schedule" would be easier to understand for many and is  
>> probably more broadly useful, but "callback" does have an  
>> important meaning too and so should be maintained. Besides, I more  
>> likely to mis-spell schedule during live coding performances :)
>>
>> Cheers,
>>
>> Andrew
>>
>> On 29/12/2009, at 3:32 PM, Andrew Sorensen wrote:
>>
>> > I'm thinking of changing the symbol name callback to schedule?
>> >
>> > callback will still work as an alias but documentation would start
>> > using schedule
>> >
>> > Any thoughts?
>> > Got a better name?
>> > Good idea, bad idea, don't care?
>> > _______________________________________________
>> > Impromptu mailing list
>> > Impromptu at lists.moso.com.au
>> > http://lists.moso.com.au/mailman/listinfo/impromptu
>>
>> _______________________________________________
>> Impromptu mailing list
>> Impromptu at lists.moso.com.au
>> http://lists.moso.com.au/mailman/listinfo/impromptu
>>
>>
>>
>> -- 
>> ----------------------------------------
>> Christopher Chong
>> Composition for Screen
>> Royal College of Music
>> SW7 2BS
>> http://www.MajorC.co.uk
>> http://majorc.wordpress.com
>> ----------------------------------------
>> _______________________________________________
>> Impromptu mailing list
>> Impromptu at lists.moso.com.au
>> http://lists.moso.com.au/mailman/listinfo/impromptu
>
> _______________________________________________
> Impromptu mailing list
> Impromptu at lists.moso.com.au
> http://lists.moso.com.au/mailman/listinfo/impromptu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.moso.com.au/pipermail/impromptu/attachments/20100103/17199c97/attachment-0001.htm