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 

> 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.


This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Tnfox-discussion mailing list

Reply via email to