RE: [Flightgear-devel] multi-threading

[Norman V. <nh...@ca...>]

 Alex Perry writes:
>
>> When I first learnt socket programming I remember having 
>read that if two
>> processes communicate using sockets on the same host the 
>results could be
>> *unpredictable*.
>
>One of the benefits of working under Windows.  Loopback socket 
>traffic works
>on Unix hosts ... and _has to_, because the operating system 
>relies on it.

FYI
Currently there is an active thread 
"Inerprocess communication"
on the game developers algoritms list
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list

Cheers

Norman

---- Windows specific advice straight from the horses mouth follows ----

That works pretty well. If you don't want to synchronised by the message
pump, then a good alternative is to use shared memory via a file mapping
object and create some synch objects (mutexes and events) to control
access to it. Another alternative is to use COM to do RPC calls between
different components - marshalling the interface across process
boundaries. The COM approach would allow you to transparently move to a
networked situation using DCOM with virtually no code change if you
needed to.

Pros and cons of above:

WM_COPY Pros: Easy to implement
WM_COPY Cons: Always synchronised by the message pump, multithreading
trickier.

Filemapping Pros: Efficient, can do sophisticated synchronisation
Filemapping Cons: Need to handle synchronisation yourself

COM/DCOM Pros: Can easily move transparently to DCOM for networked
situation if need be
COM/DCOM Cons: Need to marshall interfaces, DCOM may be less efficient
than custom network solution

I'll also repeat the comment I made when this topic came up earlier -
that on Windows, a more efficient solution is often to keep everything
in the same process in the first place and use multithreading. Depending
on the details of your situation, this may or may not be practical.

Tony Cox - Lead Engineer
Windows Gaming Developer Relations Group
http://msdn.microsoft.com/directx