The interaction would be slower, and the installation
/ integration would be more complex.
I'd like to understand better what sort of calls you wanted to make
from C to Squeak. I was thinking the reason you wanted Squeak
included was for some non-trivial processing, so the socket time
might not matter much. If you are calling Squeak to convert a
character from upper to lowercase, then interaction would be
noticeably slower. Could you give an example or two?
Squeak would be used as an extension language to a C based app. Sometimes the C code would be enumerating through a bunch of records. If a certain flag was set it would indicate that that client had a custom calculation being performed. So Squeak would be called for each record read by the C code in order to perform the custom calculations.
In other circumstances, the C app would call Squeak, and Squeak would generate a custom screen (recursively) calling the C app to create the custom screen in a totally native way. While processing the screen, Squeak may call C to perform a calculation, and that calculation may recursively call Squeak to do a portion of it.
The app is millions of lines long and integrates with its extension language in many, many places. The calls can occur in a variety of sequences. Each call must be thought of as totally independent of all the other calls and the recursive layers.
So, the answer to your question is that the calls to Squeak could be very trivial, and very non-trivial.
Back then, all we did was install the exe on the
server. Client computer connection merely loaded the latest exe.
No need to startup another app and share a socket, etc.. This
would never work in instances where you have 100 users all on
different machines. You'd have one conflict after another.
So, in your ideal world, where did Squeak get installed? Bundled in
the C app on each client? As a separate app on each client? Once on
a server somewhere?
First I made a typo. It should be 1000 and not 100 users.
I would want to statically link the Squeak kernel to my app. Only one instance of the app exists on a shared drive on the server. Each client loads their own copy of the shared exe.
Also, doing it in a client/server motif as you describe means
that any global state information made by one call would affect
other calls.
Why would there be any global information? If client #27 sent a
request to the squeak app, the squeak app could limit its response
to data that client would need to know.
You may be correct if I was writing all the extension code but that is not true. Many other developers would be creating the extensions. I could never guarantee that no one would create any global state. I need to be able to let them do whatever they like, and that it all gets erased when they exit the call. This keep each piece of code isolated from the other.
In true reentrancy each recursive call would essentially get
their own VM.
They could, but what's in the VM that they really need a separate
copy of?
Seems
like you could do that fairly easily without making
the VM re-entrant (whatever that might mean/entail). If
you thought of your Squeak app and your C app as two
computers on a network, they could send each other
requests and responses all day long. No magic required.
Cheers,
Bob
On 12/3/12 10:10 AM, Blake McBride wrote:
Greetings,
I tried to integrate Squeak to a C based
application more than six years ago. The
project failed because we were not able to have
our application call Squeak, then have Squeak
call the application, and then the application
call Squeak again recursively. An analysis of
the Squeak VM revealed a kernel design
consisting of a lot of global variables - quite
unnecessarily. The unnecessary use of global
variables over a localized structure for example
unnecessarily prevented the use of Squeak as an
extension language (unless you had no
recursion). I spent several days trying to
re-structure the Squeak kernel but I kept
running into problems and just ran out of time.
As a side note, that company I was with ended
up making a lot of investment in Scheme because
we were easily able to integrate that language
with our application. Now, not only is Scheme
used heavily within that company but many of
their clients use it too to customize their
application.
This brings me to my question, is COG
reentrant? If not, as the author of COG, I
would think it relatively easy to restructure it
to be so. Such a design capability can make a
huge difference to COG's acceptance to many. It
may even be the reason to switch to COG.
These fix a bug with pc mapping
that could cause the Vm to crash on simple
loops containing arithmetic on constants
(e.g. 1 to: 20 do: [:i| 1=1]). They also
cause the instantiation primitives to pop
all their arguments rather than assume their
argument count is 0 or 1. More change info
available in the directory. --
best,