On 26 Sep 2008 at 2:24, Ck wrote:

> I found problem: Previously I compiled dll project with  FOX_BIGENDIAN
> and now (after I looked at scons build log) I compile with FOX_BIGENDIAN 
> = 0.
> It works.

Well scons does the right thing here except on Mac OS X where for 
some odd reason Apple have miscompiled python such that it sometimes 
makes mistakes.

> I used QPipe for FXIPCChannel.
> 
> As I understand, QPipe is not good choice for connecting more than 2 
> threads...
> (I checked maxAtomicLength()  - 4096).

There can only ever be one receiving thread but many sender threads. 
This applies to QPipe, QLocalPipe or anything else.

Actually, you /could/ have multiple threads receiving too so long as 
only one is doing it at any one time. I have a special case in Tn 
where one thread receives one message and then hands off message 
receiving to a child thread.

> QLocalPipe is better for me (for intra-process communications).
> I checked QLocalPipe code: CHUNKSIZE (64*1024). Maybe this will be 
> enough for  messages..
> I can use QLocalPipe with many threads, rigth?

The 4Kb limit for QPipe is a system imposed limit. In fact it varies 
on different operating systems ... Apple & FreeBSD will automagically 
extend the pipe buffer dynamically up to 16Kb, Windows will allocate 
64Kb if you pass isDeepPipe=true to the QPipe constructor. Linux is 
fixed at 4Kb no matter what.

> But I can't connect via QLocalPipe.
> 
> Here how I do this:
> 
> On server side:
>  >  FXERRHM(pipe = new QLocalPipe);
>  >  pipe->create(IO_ReadWrite);
>  >  FXERRHM(p = new ServerConnector(this, *pipe));
> 
> On client side:
>  >  FXERRHM(pipe = new QLocalPipe(Global::pipe->clientEnd()));
>  >  pipe->open(IO_ReadWrite);
>  >  FXERRHM(wc = new ClientConnector(this, *pipe));
> 
> This is not worked..
> If use QPipe in this way - It works.
> 
> Can you tell me where my mistake?

I'll be honest: there has been a long standing bug in QLocalPipe as 
mentioned in Todo.txt which somehow causes it to fail when working 
under QSSLDevice. I have never discovered why it fails ... it has 
always seemed to work under FXIPCChannel, indeed Tn uses it, so 
obviously QSSLDevice sends some pattern of messages which makes it 
trip over.

It is possible that by sheer chance your code happens to duplicate 
this pattern and thus it fails. I can tell you that your code looks 
absolutely fine and I can't see why it wouldn't work. As you said, if 
it works via QPipe, it should work via QLocalPipe. Still, try a 
QBlkSocket just to make sure, you never know.

> PS. BTW, Niall, in QLocalPipe documentation:
>  > See QPipe for more information about how such objects work. One 
> difference that there is no create(), instead there is an otherEnd() 
> method which returns ...
> otherEnd() ?? The typing error seems to me here... And Should be 
> clientEnd() instead otherEnd().

Yes this is definitely a typing error. I'll flag this for fixing next 
time I am on the desktop computer.

Thanks for the typo report, and sorry that I am not more useful for 
QLocalPipe. By the way, what kind of application are you developing?

Thanks,
Niall




-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Reply via email to