Re: [Tnfox-discussion] IPC message sending problems
Brought to you by:
ned14
From: Niall D. <s_s...@ne...> - 2008-09-29 20:55:14
|
On 28 Sep 2008 at 4:52, CK wrote: > > Actually, you /could/ have multiple threads receiving too so long as only one > is doing it at any one time. > > So I can use many threads with QPipe to send messages without any extra > synchronisation? > In doc: > Reads and writes are threadsafe, but you should avoid more than > two threads working with > the same pipe (the same as more than two processes) because ... Yes so long as you can guarantee that no two threads will be writing simultaneously. You can either employ a mutex, a wait object or simply structure your code appropriately. If the messages are small then you shouldn't even need any extra synchronisation so long as the receiver processes messages quickly. > > By the way, what kind of application are you developing? > > I'm developing application for Stock market. > I need to rewrite dll for application named Anvil. > Old dll is singlethreaded and it can't work with big dataflow. > I trying to implement multithreaded architecture. > > Already has passed a lot of time, and I still try to understand > some components. I found your fox-toolkit fork near 2 years ago. > Now I decided to use it in this project. > Jeroen's fox-toolkit and your TnFox are very intresting thigs). > But i never used TnFox before. Just a little fox-toolkit - hello-world > application)). > So sorry for stupid questions. That's no problem. TnFOX scares away most programmers - a lot of CS courses use it as a teaching aid for advanced C++ techniques but no one that I know of uses it for actual application programming. > Yet another couple of questions: > How to use QPipe with more than one sender thread? > On client side I tried to make the test: > > > FXERRHM(pipe1 = new QPipe("pipe")); > > pipe1->open(IO_ReadWrite); > > FXERRHM(wc = new ClientConnector(this, *pipe1)); > > wc->channel()->start(true); > > ... > > FXERRHM(pipe2 = new QPipe("pipe")); > > pipe2->open(IO_ReadWrite); > > FXERRHM(wc2 = new ClientConnector(this, *pipe2)); > > but > > pipe2->open(IO_ReadWrite); > > waiting something.. > I checked with debugger. It happen on this line in qpipe.cxx: > > FXERRHWINFN(WaitNamedPipe(temp.buffer(), NMPWAIT_USE_DEFAULT_WAIT), readname); > > If I do like this: > > > FXERRHM(wc2 = new ClientConnector(this, *pipe1)); > > everything goes fine and I can send messages via wc()->channel() and > wc2->cannel(). But maybe this is not correct? No you need to create() the server end of the pipe and open() the client end of the pipe. > How do you think maybe it is better to use event loops (FXEventLoop) for > communicating threads. > For async calls use postAsyncMessage (for example for sending data to GUI), > and for sync calls use: > > RetType SomeObject::syncCall() > { > someThread->getEventLoop()->postAsyncMessage(bla-bla); > waitReturnValue(); > return retVal; > } > > void SomeObject::tryHandle(FXObject *sender, FXSelector sel, void *ptr) > { > if(sender == someThread && maybe_additional_condition){ > retVal = ptr; > endWait(); > } > .. > } > > or something like this.. > But i prefer to use IPC - it is easier. There's no synchronous call ability for async messages - it's a fire & forget system. You can of course fire an async message back again when done. The IPC mechanism is much better designed for this sort of stuff - but then the threaded windowing system was originally designed as a standalone patch for FOX and so I kept it separate. Jeroen refused the patch unfortunately and is proceeding his own direction. I'll try merging his changes with mine when FOX v1.8 comes out. > Is method with EventLoops faster? or IPC faster? > In fact I planned to use EventLoops for async calls and IPC for sync calls... IPC is definitely faster as it skips the windowing systems which is slow. > I found some (maybe) bugs... > 1) Simple test: > QFileInfo info; > > info.setFile("filename.suffix"); > fxmessage("1. Basename:%s suffix:%s\n", info.baseName().text(), > info.extension().text()); > > info.setFile("c:\\path\\filename.suffix"); > fxmessage("2. Basename:%s suffix:%s\n", info.baseName().text(), > info.extension().text()); > > info.setFile("/usr/local/filename.suffix"); > fxmessage("3. Basename:%s suffix:%s\n", info.baseName().text(), > info.extension().text()); > > info.setFile("f.s"); > fxmessage("4. Basename:%s suffix:%s\n", info.baseName().text(), > info.extension().text()); > > Output: > 1. Basename:filenam suffix:suffix > 2. Basename:filenam suffix:suffix > 3. Basename:filenam suffix:suffix > 4. Basename: suffix:s > > Something wrong here) Oh yes. I'll tag that for doing something about it. Thanks. > 2) In FXTable: > The "down"-arrow is displayed if we call > getColumnHeader()->setArrowDir(FXHeaderItem::ARROW_NONE). > But it must be displayed if we call > getColumnHeader()->setArrowDir(FXHeaderItem::ARROW_DOWN). That's probably a bug in Jeroen's code, but I'll tag that too. Thanks, Niall |