[muscle] Re: Server Design issue.

  • From: "Jeremy Friesner" <jaf@xxxxxxxxxxxx>
  • To: muscle@xxxxxxxxxxxxx
  • Date: Wed, 15 Oct 2003 09:01:38 PDT (-0700)

Hi David,

> I have a server design question.
> 
> I want my server to be part of another application, that is, the server
> should not be a stand-alone application. In my application I want to do a
> lot of tasks and might suddenly want to start a muscle server, do some other
> things, and suddenly restart the muscle server etc.
> 
> Do I need to have the ServerProcessLoop running in a separate thread=3F (This
> works but I don't know if it is the best solution). Is there any other nice
> technique that can be used to achieve this=3F

There isn't a good way to have a server running in the same thread as another
event loop, AFAIK.  However, that doesn't mean it has to be a separate 
application.

Having the server in a separate thread will work (just make sure you don't
define the MUSCLE=5FSINGLE=5FTHREAD=5FONLY preprocessor constant if you do
that).  Another possible technique, which I use in one of my applications, is to
launch the server's entry point in a separate process, by relaunching argv[0],
with a special argument indicating to the new process that it should be a server
process rather than the normal app behaviour.  Qt's QProcess class works well 
for that--if you want I can send you some of the code I use to start and stop 
the 
daemon sub-process.  The major benefit of having the server in a separate 
process
is there is no chance of race conditions, etc.

> I have a class CNbServer that inherits from muscle::Thread. It has a member
> variable that points to a muscle::ReflectServer object. In the CNbServer's
> InternalThreadEntry method I call PutAcceptFactory and starts
> ServerProcessLoop. I get afraid of all these threads running around... Is
> this approach bad or good=3F Is there something I have to keep in mind, such
> as mutex protecting access to some data/methods=3F

That should work fine... the things to keep in mind are the preprocessor 
constant
mentioned above, and that you generally shouldn't directly call methods on your 
sub-thread's ReflectServer (or its components) from your main thread, or vice 
versa.  
(if you want to control the sub-thread's behaviour interactively, the best way 
is to 
connect to via TCP and send it Messages instead).  One last gotcha is this:  
Iterating 
over the entries in a Hashtable or the fields in a Message looks like it should 
be a 
read-only operation with respect to the Message, but it isn't -- the iterators 
"register" 
themselves with the Hashtable/Message, and therefore modify its state.  This 
means 
that two threads iterating over the same Hashtable/Message at once can cause 
crashes due to race conditions in the registered-iterators list.  The upshot of
that is:  once you send a Message to your sub-thread (or vice versa), you 
should be
careful what you do with that Message afterwards.

Jeremy


Other related posts: