Callbacks from C into Squeak

> Callbacks from C into Smalltalk
>
> We currently use VSE (Visual Smalltalk Enterprise). If you have a C
> callback into VSE, while the callback is running, it is very difficult
> to debug. If the callback halts, or there is an error, you can't debug
> and resume in the normal way that you can in Smalltalk. Apparently  
> this
> is something to do with VSE using the machine stack as the Smalltalk
> stack.
>
> However, one of the nice things about VSE is: if I put a halt in the
> callback, will I see the entire stack, including the methods before  
> the
> initial entry into C. Also if I throw an exception in the call back
> that is not caught in the callback, will it be caught further down the
> stack by code running before the initial entry into C. If it a
> resumable exception, I can resume as per normal.
>
> Now, we do a lot of numerical computing, re-using all the C and  
> Fortran
> libraries that are already out there. It is common in a numerical
> library to use callbacks. Say you want to integrate f(x). The
> integrator is written in Fortran, and f(x) is written in Smalltalk.  
> You
> need a way for the integrator to call f(x), and you do that with a
> callback. So to leverage these libraries we need an easy way to do
> callbacks, and once you have a callback you need a way of debugging
> these callbacks that a mathematician (rather than a comuputer
> scientist) will feel comfortable with.
>
> So my questioin is: when you callback into Squeak from C/Fortran,
> can you throw and catch exceptions, halt, debug and resume execution
> of the callback in the normal Smalltalk way. Or does the fact that
> you are in a callback compromise Smalltalk's usual execution?
>
> Cheers
>
> Daniel
>
>

> Well you can't callback from C to Squeak, once you are in a primitive
> call the interpeter is suspended, triggering a GC event requires
> special care to ensure object pointers you many have will still be valid
> (remapped) after the GC completes.  You can of course do a limited set
> of VM calls to manipulate or make new object, but that does not include
> running byte codes.  Likely this can be overcome by $ (euros preferred).
>
> Other options include running a VM (or VMs) as a sub process and talking
> to it via pipes or shared memory areas for it to do computational work.  
> Technially this is done by mac carbon and unix VM when they run headless
> to provide support as a browser plugin.
>
>
> On Dec 14, 2006, at 6:17 AM, daniel poon wrote:
>
>> Callbacks from C into Smalltalk
>>
>> We currently use VSE (Visual Smalltalk Enterprise). If you have a C
>> callback into VSE, while the callback is running, it is very difficult
>> to debug. If the callback halts, or there is an error, you can't debug
>> and resume in the normal way that you can in Smalltalk. Apparently this
>> is something to do with VSE using the machine stack as the Smalltalk
>> stack.
>>
>> However, one of the nice things about VSE is: if I put a halt in the
>> callback, will I see the entire stack, including the methods before the
>> initial entry into C. Also if I throw an exception in the call back
>> that is not caught in the callback, will it be caught further down the
>> stack by code running before the initial entry into C. If it a
>> resumable exception, I can resume as per normal.
>>
>> Now, we do a lot of numerical computing, re-using all the C and Fortran
>> libraries that are already out there. It is common in a numerical
>> library to use callbacks. Say you want to integrate f(x). The
>> integrator is written in Fortran, and f(x) is written in Smalltalk. You
>> need a way for the integrator to call f(x), and you do that with a
>> callback. So to leverage these libraries we need an easy way to do
>> callbacks, and once you have a callback you need a way of debugging
>> these callbacks that a mathematician (rather than a comuputer
>> scientist) will feel comfortable with.
>>
>> So my questioin is: when you callback into Squeak from C/Fortran,
>> can you throw and catch exceptions, halt, debug and resume execution
>> of the callback in the normal Smalltalk way. Or does the fact that
>> you are in a callback compromise Smalltalk's usual execution?
>>
>> Cheers
>>
>> Daniel
>>
>>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>

> http://lists.squeakfoundation.org/pipermail/vm-dev/2006-June/ 
> 000748.html
>
> Cheers,
>   - Andreas
>
> John M McIntosh wrote:
>> Well you can't callback from C to Squeak, once you are in a  
>> primitive call the interpeter is suspended, triggering a GC event  
>> requires

> John M McIntosh <johnmci <at> smalltalkconsulting.com> writes:
>
>> Well you can't callback from C to Squeak, once you are in a primitive
>> call the interpeter is suspended, triggering a GC event requires
>> special care to ensure object pointers you many have will still be
>> valid (remapped) after the GC completes.  You can of course do a
>> limited set of VM calls to manipulate or make new object, but that
>> does not include running byte codes.  Likely this can be overcome by
>> $ (euros preferred).
>
> Thanks for the answer John.
> If I communicate with the DLL with primitive date allocated on the  
> C heap, then
> I don't mind if Squeak objects move around anymore. Am I still  
> prevented from
> calling back into Squeak?
>
>> Other options include running a VM (or VMs) as a sub process and
>> talking to it via pipes or shared memory areas for it to do
>> computational work.  Technially this is done by mac carbon and unix
>> VM when they run headless to provide support as a browser plugin.
>
> How do you get UI events into Squeak without callbacks?
>
> Cheers
>
> Daniel
>
>

> On Dec 16, 2006, at 19:14 , daniel poon wrote:
>
> > If it is a callback that requires an answer (e.g. 'give me the  
> > contents for this
> > list box'), what do  you do?
>
> Easiest might be to use a toolkit that does not require callbacks ;)  
> Otherwise there is no way to do that in FFI only I think. You could  
> write a plugin that forks off another process which will talk to your  
> toolkit.

> Bert Freudenberg <bert <at> freudenbergs.de> writes:
>
> > On Dec 16, 2006, at 19:14 , daniel poon wrote:
> >
> > > If it is a callback that requires an answer (e.g. 'give me the  
> > > contents for this
> > > list box'), what do  you do?
> >
> > Easiest might be to use a toolkit that does not require callbacks ;)  
> > Otherwise there is no way to do that in FFI only I think. You could  
> > write a plugin that forks off another process which will talk to your  
> > toolkit.
>
> When you say <<forks off another process>>, do you mean a Smalltalk process?

> 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.

> 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.

> 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

> David T. Lewis wrote:
> >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
>
> Hi Dave
>
> That makes it an overhead 0.15ms per callback, which is acceptable. I
> will need to pass back an forth a packed array of floating point numbers
> with a few hundred elements in it (representing the state of the system
> and its calculated derivative). How could that be achieved without
> denting that 0.15ms overhead too much?

> David T. Lewis wrote:
>>  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:

> I've worked with mainframe computers of these people (beware: gif patent  
> holders)
>
> - http://www.google.com/search?q=WebTx+ipc+shared+memory
>
> for quite some time. We had a supplemental Unix box integrated into the  
> mainframe (other users choose to integrate MS boxen) for various purposes.  
> The interface was very versatile and the fastest transport was shared  
> memory (of course, for very high volume bank transactions ...). IIRC this  
> interface establishes connection using pipes and then just tells "new data  
> arrived" (like with your call/callback), after updating shared memory.
>
> Perhaps such a shared memory approach is of use for you, perhaps in  
> concert with Dave's pipe solution (but I don't know of any Squeak support  
> for shared memory).

> On Mon, Dec 18, 2006 at 06:42:35PM +0100, Klaus D. Witzel wrote:
>> I've worked with mainframe computers of these people (beware: gif  
>> patent
>> holders)
>>
>> - http://www.google.com/search?q=WebTx+ipc+shared+memory
>>
>> for quite some time. We had a supplemental Unix box integrated  
>> into the
>> mainframe (other users choose to integrate MS boxen) for various  
>> purposes.
>> The interface was very versatile and the fastest transport was shared
>> memory (of course, for very high volume bank transactions ...).  
>> IIRC this
>> interface establishes connection using pipes and then just tells  
>> "new data
>> arrived" (like with your call/callback), after updating shared  
>> memory.
>>
>> Perhaps such a shared memory approach is of use for you, perhaps in
>> concert with Dave's pipe solution (but I don't know of any Squeak  
>> support
>> for shared memory).
>
> Interesting idea. There is no support for shared memory in Squeak  
> right
> now, but in principle it's no different from other OS and C runtime  
> calls
> in the OSProcessPlugin. I think that the shared memory interface  
> for Unix
> platforms is fairly well standardized, and there are Win32 analogues,
> so that it could be provided across most platforms.
>
> Dave
>
>

> On Mon, Dec 18, 2006 at 10:11:46AM +0000, dan wrote:
>> Hi Dave
>>
>> That makes it an overhead 0.15ms per callback, which is acceptable. I
>> will need to pass back an forth a packed array of floating point numbers
>> with a few hundred elements in it (representing the state of the system
>> and its calculated derivative). How could that be achieved without
>> denting that 0.15ms overhead too much?
>  
> Daniel,
>
> The only way to find out is to try it. Do you have an example of the
> packed array binary data to work with? We could plug it in to the test
> and see what happens.
>
> Dave