On Sun, Dec 17, 2006 at 12:50:09PM -0500, David T. Lewis wrote:
> On Sun, Dec 17, 2006 at 04:56:45PM +0000, daniel poon wrote:
> > David T. Lewis <lewis <at> mail.msen.com> writes:
> > > Bert is referring to an OS process (unix, win32), not a Smalltalk
> > > process. So the plugin could fork an OS process and communicate with
> > > it through any of several mechanisms.  But his suggestion of a toolkit
> > > that does not require callbacks is really the first thing that you
> > > should consider.
> > 
> > Thanks for your clarification and your code snippets. 
> > I was using the GUI callback as an illustration of a callback, but what I am
> > really interested in is calling back from foreign mathematical libraries, and
> > how to do that in Squeak. We have had some success in doing such things in
> > another Smalltalk dialect, and I want to know if I can port that work on to 
> > Squeak. 
> > 
> > Will using separate processes perform well enough? To simulate a few seconds
> > using a physics simulation, a maths library would have to make about a million
> > callbacks into Smalltalk. You would want the simulation to take seconds or
> > minutes rather than hours. 
> 
> My guess is that separate processes would *not* perform well enough, but my
> guessing does not count for much. If you have a fairly good idea of how many
> callbacks are happening, it might be worth putting together a no-op test
> to find out how fast it runs. You could for example run a million transactions
> with Squeak sending "hello there" (and flushing the stream), and a C program
> echoing the message back but otherwise doing nothing. The results will
> probably be disappointing, but you never know.

Daniel,

To follow up on my comment above, I put together a test that has Squeak
forking another Squeak image, then sending 'hello' back and forth a million
times between the two images, each of which is running in a separate OS
process. The one million transactions run in about 150 seconds on my 166MHz
Pentium. I guess that on faster hardware it would do better.

So somewhat to my surprise, it does seem reasonable to consider using simple
communications through a pipe for the kind of work you are describing, and
expect performance in the "minutes not hours" range.

Here is the test that I ran:

    | sendPipe receivePipe s remote count |
    count := 1000000. "One million transactions"
    sendPipe := OSPipe blockingPipe.
    receivePipe := OSPipe blockingPipe.
    remote := UnixProcess forkHeadlessSqueakAndDoThenQuit:
        ["This block is evaluated in the remote headless Squeak image"
        (count + 1) timesRepeat:
            ["Read message and echo it back to sender"
            s := sendPipe next: 5.
            receivePipe nextPutAll: s; flush]].
    remote inspect. "Inspect the process proxy for the remote Squeak"
    sendPipe nextPutAll: 'hello'; flush.
    receivePipe next: 5. "do one complete transaction before starting the timer"
    (Time millisecondsToRun:
        [count timesRepeat:
            [sendPipe nextPutAll: 'hello'; flush.
            receivePipe next: 5]]) inspect. "Inspect run time in milliseconds"
    sendPipe close.
    receivePipe close.


Dave