[sldev] On making threads less complex with using g-objects

Dzonatas Sol dzonatas at gmail.com
Fri Jun 12 22:13:43 PDT 2009


The interest is to allow several languages access to a base dynamic 
shared object (i.e. DLL) given an API that can be used across each language.

Some languages provide their own methods for process threads. If the API 
supports an abstract class that can be used across each languages, then 
this is the kind of standardization that is less complex. The interface 
is the same instead of the complexity of many different implementation 
across each language. There is also further complexity when a specific 
language actually is actually supported by its hosts environment, which 
is common with virtual machines. These VMs work best when the threads 
are controlled by the VM instead of by the guest environment, the DLL in 
this case. There are some advanced topics about this I'll avoid here.

When you run the viewer as a standalone executable, it is its own host 
and guest.

The viewer doesn't need to be a standalone executable, as the base code 
for it could support an API as noted above. This essentially turns what 
was the viewer into a DLL.

The communication layer in-n-out of the blackbox, like between the DLL 
and any specific language, is the g-objects. I think some were confused 
by that with the mention of other languages.

This is beyond the proof-of-concept stage. To pick out a use case, I'd 
point out the need for a multi-threaded API that works for each language.


More information about the SLDev mailing list