[muscle] Re: muscle + Qt + console apps

Hey David,

If your program has no GUI at all (i.e. it's just running from the 
command line or as a server), then perhaps you don't need to
have a separate thread=3F  You could just write your program
in the standard muscle-server model, and call AddNewConnectSession()
with a session object that represents your connection to the remote server.
Then muscle's ReflectServer::ServerProcessLoop() would handle everything,
and you could put your logic into your session subclass's 
AsyncConnectCompleted(), MessageReceivedFromGateway(), and 
ClientConnectionClosed() event
callback methods.  Having only a single thread would probably make your 
program simpler, too.

Without a GUI, the only reason you would really need a separate thread
is if there is some blocking (or very time-consuming) operation that your
code needs to do, and you want that code to execute in a separate 
thread so that it doesn't affect the responsiveness of the other operations
your program needs to do.  Let me know if that is the case -- if so, I can 
post information about how to add to a ReflectServer a session that is an 
interface to a sub-thread.

Jeremy

ps Regarding a "PThreadMessageTransceiverThread"... the 
     MessageTransceiverThread class pretty much already is that,
     since it uses pthreads internally (if you define MUSCLE=5FUSE=5FPTHREADS).
     The only thing you might find wanting about it is its SignalOwner() method 
--
     in the default MessageTransceiverThread class, SignalOwner() signals the 
master
     thread by sending a byte on a socket that the master thread should
     be listening to.  If you know of a better thread-notification-mechanism,
     you could subclass MessageTransceiverThread class with your own
     subclass that implements SignalOwner() some other way.

> Hi guys, thanks for all answers! I really appreciate them.
> 
> Well, I'm having some problems with my MessageTransceiverThread. Previously
> I used Win32MessageTransceiverThread with success, but since I figured out I
> wanted to support Linux the only alternative I could figure out was to use
> Qt, and hence QMessageTransceiverThread.
> 
> Then Qt started to frustrate me. Qt's event loop works nicely in GUI based
> applications where everything is event-based. But my little application do
> not need any cool buttons to start executing, it should just plain and
> simply run. How do I do this=3F
> 
> i.e.
> int main( int argc, char** argv )
> {
>   muscle complete setup system
>   QApplication qApp( argc, argv, false ); // console
>   my way to connect to server need Qt event loop
>   return qApp.exec( ); // started way to late!
> }
> 
> Any ideas=3F
> 
> Is there another alternative to QMessageTransceiverThread to "muscle"
> cross-platform=3F

Other related posts: