|
»
Re: Uncaught bounce notification
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: IPC message sending problems
by CK-8
::
Rate this Message:
>> The attached message was received as a bounce, but either the bounce >> format was not recognized, or no member addresses could be extracted >> from it. This mailing list has been configured to send all >> unrecognized bounce messages to the list administrator(s). >> > > Looks like you had a problem reaching the list. > > Sorry, i wrote wrong email - tnfox-discussion-bounces@... > Are you sure you are defining & registering the message chunk > correctly as per the documentation and source code examples? > > I looked at the docs & TestIPC example and I do the only the following steps for defining & registering IPC messages: > typedef FX::FXIPCMsgChunkCodeAlloc<0x80, true> MsgChunkBegin; > struct TestMarketMsg_Error : public FX::FXIPCMsg > { > typedef FX::FXIPCMsgChunkCodeAlloc<MsgChunkBegin::code, false> id; > typedef FX::FXIPCMsgRegister<id, TestMarketMsg_Error> regtype; > int code; > TestMarketMsg_Error() : FX::FXIPCMsg(id::code), code(0) { } > TestMarketMsg_Error(int c): FX::FXIPCMsg(id::code), code(c){} > void endianise(FX::FXStream &ds) const { ds << code; } > void deendianise(FX::FXStream &ds) { ds >> code; } > }; > //-------------------------------------------------------------------------------- > struct TestMarketMsg_Action : public FX::FXIPCMsg > { > typedef FX::FXIPCMsgChunkCodeAlloc<TestMarketMsg_Error::id::nextcode, false> id; > typedef FX::FXIPCMsgRegister<id, TestMarketMsg_Action> regtype; > int code; > TestMarketMsg_Action(int c=0) > : FX::FXIPCMsg(id::code), code(c){ } > void endianise(FX::FXStream &ds) const { ds << code; } > void deendianise(FX::FXStream &ds) { ds >> code; } > }; > //-------------------------------------------------------------------------------- > > typedef FX::FXIPCMsgChunk<FX::Generic::TL::create< > TestMarketMsg_Error::regtype, > TestMarketMsg_Action::regtype > >::value> MsgChunk; and in class: > void IPCController::channelInstall() > { > FXERRHM(m_chunk = new MsgChunk(&m_channel->registry())); > ... after > TestMarketMsg_Action act(1); > wc->channel()->sendMsg(act); I have the exception. > Your error above suggests a serialisation/deserialisation mismatch in > the message sent before that message - the exception you got is a > trap for that problem. There is some #ifdef DEBUG code in the > FXIPCChannel source which may help and there are even more debug > outputs which can be commented into working too. One of them even > dumps a byte output of bytes received & sent so you should definitely > find where the problem is. > > Ok, I'll try to use this. Thanks for your answers, 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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
|
|
|
|
|
|
|
|
Re: IPC message sending problems
by Niall Douglas
::
Rate this Message:
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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
|
|
Re: IPC message sending problems
by CK-8
::
Rate this Message:
> 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 ... > 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 is sad.. I'll try to use QPipe. > Still, try a QBlkSocket just to make sure, you never know. > Hm. I have some technical problems with testing QBlkSocket. Maybe I'll try it later. > 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. I 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. 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? 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 <../../d5/d5a/class_f_x_1_1_f_x_object.html> *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. Is method with EventLoops faster? or IPC faster? In fact I planned to use EventLoops for async calls and IPC for sync calls... 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) 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). Thank you. ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
|
|
Re: IPC message sending problems
by CK-8
::
Rate this Message:
My mail server have problems.. I posted this answer from gmane.org.
> 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 ... > 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 is sad.. I'll try to use QPipe. > Still, try a QBlkSocket just to make sure, you never know. > Hm. I have some technical problems with testing QBlkSocket. Maybe I'll try it later. > 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. 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? 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. Is method with EventLoops faster? or IPC faster? In fact I planned to use EventLoops for async calls and IPC for sync calls... 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) 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). Thank you. ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
|
|
Re: IPC message sending problems
by Niall Douglas
::
Rate this Message:
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 ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
|
|
Re: IPC message sending problems
by CK-8
::
Rate this Message:
Niall Douglas <s_sourceforge@...> writes:
> > > 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. > This scares me more than TnFox). Do you use TnFox? > No you need to create() the server end of the pipe and open() the > client end of the pipe. I do not understand.. I do the following: Server side: > FXERRHM(pipe = new QPipe("pipe")); > pipe->create(IO_ReadWrite); > FXERRHM(p = new ServerConnector(this, *pipe)); Client1: > FXERRHM(pipe1 = new QPipe("pipe")); > pipe1->open(IO_ReadWrite); > FXERRHM(wc = new ClientConnector(this, *pipe1)); > wc->channel()->start(true); Client2: > FXERRHM(pipe2 = new QPipe("pipe")); > pipe2->open(IO_ReadWrite); > FXERRHM(wc2 = new ClientConnector(this, *pipe2)); but Client2 wait something on pipe2->open(IO_ReadWrite); How to connect 2 or 3 clients to server via QPipe? Can you write simple example? ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
|
|
Re: IPC message sending problems
by Niall Douglas
::
Rate this Message:
On 1 Oct 2008 at 5:17, Ck wrote:
> I do the following: > > Server side: > > > FXERRHM(pipe = new QPipe("pipe")); > > pipe->create(IO_ReadWrite); > > FXERRHM(p = new ServerConnector(this, *pipe)); > > Client1: > > FXERRHM(pipe1 = new QPipe("pipe")); > > pipe1->open(IO_ReadWrite); > > FXERRHM(wc = new ClientConnector(this, *pipe1)); > > wc->channel()->start(true); > > Client2: > > FXERRHM(pipe2 = new QPipe("pipe")); > > pipe2->open(IO_ReadWrite); > > FXERRHM(wc2 = new ClientConnector(this, *pipe2)); > > but Client2 wait something on pipe2->open(IO_ReadWrite); > > How to connect 2 or 3 clients to server via QPipe? > Can you write simple example? Oh I see what you mean. You want two clients connecting to one server pipe. No that isn't supported because its behaviour doesn't match between Windows and POSIX. You can have one server QPipe and one client QPipe and multiple threads can simultaneously use both pipe objects at the same time. More than two QPipe objects per pipe is not supported. This is because Windows uses a IP socket style system of detaching pipe instances from a listening pipe whereas Unix does not. If you want one server interface and multiple clients, QBlkSocket is the only thing which does this. If you want to cheat, you could fetch the internal HANDLE, duplicate it with cross-process inheritability and pass it to the other process. I am not sure if just doing an ReadFile() on the same pipe instance string works - I am afraid I do not have the internet available to me right now so I cannot check. If you are in the same process, just reuse the same QPipe instance between threads. Hope that helps, 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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
|
|
Re: IPC message sending problems
by Ck-15
::
Rate this Message:
> If you are in the same process, just reuse the same QPipe instance
> between threads. Ok! Thanks. > Hope that helps, Yes. ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
|
|
Re: IPC message sending problems
by Ck-15
::
Rate this Message:
One more question.
Can't understand how to get ask from thread via IPC.. For example: thread_1 requests from thread_2 some actions and wants to get the result of this actions. void thread_1::req() { Msg msg(bla-bla); sendMsg(msg); // here i want to use result from thread_2. } .. thread_2::msgReceived(FXIPCMsg *rawmsg) { Msg *i = (Msg*)rawmsg; FXString result = someAction(i->data); } How to return result to thread_1? Thanks. ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
|
|
Re: IPC message sending problems
by Niall Douglas
::
Rate this Message:
On 6 Oct 2008 at 17:37, Ck wrote:
My apologies for the very late reply - my entire email processing system died for most of last week and it took the past weekend to extract my email. > One more question. > > Can't understand how to get ask from thread via IPC.. > > For example: > thread_1 requests from thread_2 some actions and wants to get the > result of this actions. > > void thread_1::req() > { > Msg msg(bla-bla); > sendMsg(msg); > > // here i want to use result from thread_2. > } > > .. > thread_2::msgReceived(FXIPCMsg *rawmsg) > { > Msg *i = (Msg*)rawmsg; > > FXString result = someAction(i->data); > } > > How to return result to thread_1? You need to define an Ack message for the message which will transport your result back to the sender. Your sender can either wait for the reply or move on with other processing, polling for the reply or indeed having a separate handler for the reply whenever it arrives. If you have an Ack message defined, TnFOX will automatically collect any C++ exceptions thrown by the remote side and return them to the message sender. I vaguely remember a system in place for timeouts as well, so if a message does not return in time you get notified and the operation is cancelled. If you check the TestIPC program for the "file access over IPC" mechanism then this gives a good demonstration of how to efficiently use Ack messages to maximise throughput and deal correctly with error situations. HTH, 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@... https://lists.sourceforge.net/lists/listinfo/tnfox-discussion |
| Free embeddable forum powered by Nabble | Forum Help |
