Multithreading confusion...

[maharaja]

Hi,

Here is the problem:

If I were coding a single-threaded game only in C++ (not using CS) here is how I'd normally do things in my main loop: read input from keyboard, move things around in the world, draw to the screen.

Thus in a multiplayer game, one could do so: read input from keyboard, read in from network, move things around in world, send messeges back to network, draw on the screen.

But this does not work if you want a fast efficient networking, so the solution is obviously to make it multi-threaded where one thread continuously reads messegaes from network and sends messages out, while another thread moves the things, draws the screen, cook some eggs and whatever...

The question is, since Crystal Space is already multi-threaded, how can one do the above most efficiently?
Should I run multiple threads myself? Or should I do things as if in a single-thread and CS would (somehow) itself take care of multi-threding it?

So for instnace, if I would do all the reading-writing to network inside processframe() how would CS handle it?

Hope I've been able to explain the question and making some sense

Any help would be greatly appreciated!

/regards

[res]

CS won't magically split things into threads for you.

You have to approach it like any other multithreading issue: with synchronization.

Note that you should restrict use of CS to a single thread. (Some interfaces are documented as "thread safe", which is, unfortunately, not entirely true.)

[rvhaasen]

As far as i know cs is -as res already mentioned- single threaded: it is basically a big event dispatcher that distributes events to registered plugins. Processing all events is done by 1 thread. So CS classes are not designed to be thread safe (this would involve embedding expensive synchronisation methods).  Each plugin is however free to use other threads, as long as these threads don't use objects that are used by the main thread (effectively meaning all cs objects) it can do whatever it wants to help speeding up some processing for the plugin.
Communication/synchronisation between the plugin and its thread can be done on many ways, 1 of them is using  message qeues. There are many libraries that abstract this in a platform independent way. I mainly use the opensource Poco library for this.

If you use the RakNet library, most of the processing will already be done by other thread(s) , the API functions (which are "executed" by the main cs thread)  communicate with the network processing thread(s) through message queues, you don't see anything of this from the "outside". As such there is no expensive processing being done by the "main cs thread" (that executes all plugin event handlers).