Some threading and COM question from a Dolphin novice

Hello Dolphin newsgroup.

I've finally found some time to play a little bit with Dolphin. I am
experienced in Smalltalk (VSE) and Windows and COM, but my Dolphin knowledge
is limited, so I have some questions regarding Dolphin 5.0 Pro.

What thread model does Dolphin use? Does it have green threads (fibers) or
does it use native OS threads?

Which thread does the garbage collector runs on? What happens to objects
when interfacing external libraries (OS, DLLs etc.). In VSE an object has to
be copied to non-Smalltalk memory and back, so the GC won't move it. In .NET
an object can be "pinned" so the GC can't move it. How has Dolphin solved
those issues?

The primary reason to play with Dolphin is to try to create in-process COM
servers (ActiveX DLLs). As far as I can see from the Object Atrs webpage,
5.0 Pro is capable of doing this. But the documentation is not finished yet.
Where can I find some tutorial on that matter?

What kind of in-proc COM servers does Dolphin create? What is the footprint?
Let's say I have a COM component with one class with one method called "foo"
that returns the string "bar". Approximately how big DLL file will be
created and what other libraries are loaded? When are they loaded one per
process, thread or pr. instance I create. What is the performance compared
to Visual Basic?

What is the threading model of the COM servers? Is it Apartment or Free or
Neutral? If Free or Neutral, are there any tools that will help me with
synchronisation? If I have a class variable (which in traditional image is
global), what is the scope of that variable? In other words, are objects
stored in the Thread Local Storage and global only within the thread (as in
Visual Basic) or are they stored globally?

If we are running Dolphin in-proc COM server and we call
Behavior>>addSelector:withMethod: to add a method on the fly, who will this
affect? Is it out thread, out process or what is the scope of that
operation?

Enough in-proc COM server stuff. The site states about a toolkit called
Lagoon. Where can I find some tutorials?

The website also states about ActiveX Scripting for interfacing to the
Microsoft ActiveX scripting control. What does that mean? The possibility to
invoke scripts in the MS script engine or more integration so that Dolphin
objects are made available in the script engine?

Is there an ObjectFiler or other tool in Dolphin that can persist and
depersist objects?

Finally, a question about the Web Applet Plug-in. I read that it's not
working any more because Microsoft have removed the Netscape API. This is
bad, but I don't think anybody can force Microsoft to put the API back in
the browser. The Web Applet Plug-in is a cool feature. Are there any plans
to port it to ActiveX and make it work in newer MS browsers? I am not sure
it's possible at all, but what about an emulator / bridge that emulates the
Netscape API in IE? I don't think Dolphin is the only product that had
encountered that issue. What have others done to solve it?

Thanks for your help!

Merry Christmas (better late than never) and Happy New Year!

-- Todor Todorov

Todor,

> What thread model does Dolphin use? Does it have green threads (fibers) or
> does it use native OS threads?

Mostly green.  Overlapped calls occur on OS threads, but AFAIK one cannot
overlap COM calls.  There has been discussion of relaxing that restriction.


> Which thread does the garbage collector runs on?

IIRC, it runs on a separate OS thread, but that's transparent.


> What happens to objects
> when interfacing external libraries (OS, DLLs etc.). In VSE an object has
to
> be copied to non-Smalltalk memory and back, so the GC won't move it. In
.NET
> an object can be "pinned" so the GC can't move it. How has Dolphin solved
> those issues?

See #newFixed:.


> The primary reason to play with Dolphin is to try to create in-process COM
> servers (ActiveX DLLs). As far as I can see from the Object Atrs webpage,
> 5.0 Pro is capable of doing this. But the documentation is not finished
yet.
> Where can I find some tutorial on that matter?

The essential feature is creating COM servers.  The in-proc part is fairly
trivial by comparison.  My newCOMer sample is one very limited example.
Blair posted a very nice procedure for using MIDL and the type library
analyzer to do the grunt work; a quick search of Ian's archives of this
group should find it.


> What kind of in-proc COM servers does Dolphin create? What is the
footprint?
> Let's say I have a COM component with one class with one method called
"foo"
> that returns the string "bar". Approximately how big DLL file will be
> created and what other libraries are loaded? When are they loaded one per
> process, thread or pr. instance I create. What is the performance compared
> to Visual Basic?

I **think** the server is loaded once per calling process.


> What is the threading model of the COM servers?

Apartment.  Dolphin is still basically single-threaded.



> If we are running Dolphin in-proc COM server and we call
> Behavior>>addSelector:withMethod: to add a method on the fly, who will
this
> affect? Is it out thread, out process or what is the scope of that
> operation?

I would first ask whether the class builder is available.  My hunch is that
it won't.


> Enough in-proc COM server stuff. The site states about a toolkit called
> Lagoon. Where can I find some tutorials?

Worst case, the D4 Education Centre contains a tutorial.


> Is there an ObjectFiler or other tool in Dolphin that can persist and
> depersist objects?

It's generally called the binary filer.  Look for STBFiler,
#binaryStoreBytes, #fromBinaryStoreBytes:.


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Todor Todorov wrote:

> I've finally found some time to play a little bit with Dolphin. I am
> experienced in Smalltalk (VSE) and Windows and COM, but my Dolphin
> knowledge is limited, so I have some questions regarding Dolphin 5.0
> Pro.

Some partial answers...

> What thread model does Dolphin use? Does it have green threads
> (fibers) or does it use native OS threads?

Dolphin uses a few real OS-level threads, but all Smalltalk code is running on
just one OS thread.  So ST "Processes" are indeed green threads, but are not
(as far as I know) Windows "fibres", and Windows is not even aware of their
existance.

One use of real OS-level threads is that external calls marked "overlapped"
(e.g. KernelLibrary>>sleep:) are implemented by executing the external call in
a background OS thread (started to order ? pooled ?) so as to allow the
Smalltalk thread to continue serving the other Processes.

As I understand it, if an external callback is made into Dolphin from an OS
thread other than the Smalltalk thread, then Dolphin will halt the external
thread, marshal the parameters over to the Smalltalk thread (somehow), and then
execute the called code in the Smalltalk thread before copying the answer back
to the original thread and resuming it.  I don't think you have any control
over what Process is used to execute the external call.

A question for Blair: is there any way to ensure that external callbacks
properly respect locked Mutexes ?  E.g. if the Process that ends up being
co-opted to execute the external call was holding a Mutex at the time, then is
there a way to ensure that the code holding the mutex is completed *before* the
external call is allowed to proceed ?  I can't think of any way to do that, but
I can't see how else to handle structures safely if they can be accessed (under
mutex protection) both from Dolphin Processes and from external callbacks.

> Which thread does the garbage collector runs on?

There is a backgound GC activity that runs every 10 seconds or so.  I think I
remember Blair once saying that that ran as an OS thread.  However, all ST
activity is suspended for the handful of millisececonds it takes to run, so it
doesn't really matter what thread its on.  Also if memory gets low despite the
background collector, then Dolphin will force a GC from the main thread, and
that (I assume) will suspend all Dolphin Processes (of whatever priority) while
it runs.

> What happens to
> objects when interfacing external libraries (OS, DLLs etc.). In VSE
> an object has to be copied to non-Smalltalk memory and back, so the
> GC won't move it. In .NET an object can be "pinned" so the GC can't
> move it. How has Dolphin solved those issues?

Bill has mentioned #newFixed:.  It's worth adding that instances of all
subclasses of ExternalStructure are fixed by default.  ExternalStructures are
what are normally used to hold data that is passed back and forth over the
external interfaces.

> The primary reason to play with Dolphin is to try to create
> in-process COM servers (ActiveX DLLs).

It can certaily be done, but I know little of these things.  There are a couple
of COM server examples in Object Arts\Samples\ActiveX, namely 'COM Random
Stream.pac' and 'EnumRECT.pac', that may help.

> Enough in-proc COM server stuff. The site states about a toolkit
> called Lagoon. Where can I find some tutorials?

You could look at the last chapter of Ted Bracht's 'Dolphin Smalltalk
Companion'.  Hoever that's only a couple of pages (deployment to a .exe in
Dolphin is almost trivially simple).  There's also an example: Object
Arts\Samples\Lagoon\Autoplay\Autoplay.pac.  I don't know if there's anything
specifically about deploying COM servers, though.

> The Web Applet Plug-in is a cool feature.
> Are there any plans to port it to ActiveX and make it work in newer
> MS browsers? I am not sure it's possible at all, but what about an
> emulator / bridge that emulates the Netscape API in IE? I don't think
> Dolphin is the only product that had encountered that issue. What
> have others done to solve it?

Someone once mentioned that the Mozzilla project had built such a bridge.  I
don't know, but searching www.mozilla.org might find something.

    -- chris