[muscle] SV: Re: Server Design issue.
- From: "David Svanberg" <ds@xxxxxxxxxxx>
- To: <muscle@xxxxxxxxxxxxx>
- Date: Wed, 22 Oct 2003 14:32:05 +0200
It should be good if one could do a ServerProcessSingleLoop that runs one
iteration through the ServerProcessLoop leaving control back to the caller.
In this case it is possible to interact with the server loop even from my
internal thread.
Or...
Having the possibility to install a callback function from the
ServerProcessLoop giving us the chance to interact.
A New Feature In The Next MUSCLE Release?
/D
-----Opprinnelig melding-----
Fra: muscle-bounce@xxxxxxxxxxxxx [mailto:muscle-bounce@xxxxxxxxxxxxx]På;
vegne av Jeremy Friesner
Sendt: 15. oktober 2003 18:02
Til: muscle@xxxxxxxxxxxxx
Emne: [muscle] Re: Server Design issue.
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:
