|
After some deliberation - I have decided to replace the whole mechanism with a shared file instead. It is a little ironic to say the least that I cannot get the pipe method to work for me - when my own application is called 'Pipelines'. Thank you for your help.
Regards.
James
|
|
|
|
|
Are you closing the pipe handle with CloseHandle() in process C before process D tries to connect?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
Thank you for looking into this for me. I am still at a loss as to why the process is not working. All the process' are synchronous - the mechanism I posted is one small part of a very big set of multi-threaded interlocked processes - however it is pretty much stand-alone - all it does is simulate the re-directed std handles of another process.
For the first time in years - I am stuck!
James.
|
|
|
|
|
I have read the entire thread so far and I think I see the problem here. The "Server" side of named pipes needs some magic in order to support multiple clients accessing it, even if those clients are "synchronized".
A named pipe is still a "one shot deal", that is, you create it, wait for a connection, accept the connection, and then close the pipe when you are all done. That means that a single "client" can access the pipe. In order for multiple clients to work, you have to have multiple instances of the "named pipe", in other words, you have lots of pipes with the same name all ready for use.
The easiest way to do this is demonstrated in the following pseudo-code (I cannot actually paste my working code as it belongs to my employer, as does my soul and first born
HANDLE P1 = create_a_named_pipe("Bob");
While (TRUE)
{
HANDLE P2 = create_a_named_pipe("Bob");
wait_for_a_connection(P1);
P1 = P2;
} ).
Anyway, you need to maintain at least one "unattached" pipe with the proper name so that clients have something to "connect to" while you are busy working with the other client or cleaning up after you are done with it.
Managing how one and only one application will have a pipe named "Bob" is an exercise for the student
|
|
|
|
|
Thank you very much for the update. I have already changed my code to use a shared file(s). Neverthless, after reading your comments - I can see exactly where my original design was wrong. I get it now. Thank you very much - this will be invaluable in other areas where I need to alter pipe processing connections.
|
|
|
|
|
Hello,
I have an application that uses a DLL but the DLL needs to access data provided by the application on runtime.
Tryng to make .exe objects visible to the DLL brings me to awful linking problems
The solution I tested is to use COM but this forces to use RPC for communication between the .DLL and the .EXE world. COM solution sounds complex and out-proc is slower than in-proc.
Please could you help me with a more simple solution?
Thank you in advance
|
|
|
|
|
What data is needed by the DLL?
You should export a function from the DLL that the EXE can call to pass in the data using function parameters.
|
|
|
|
|
Data is contained in arrays which objects are instances of classes of the application. I have tried to pass a reference of the object in the exported function but the parameter type is not known by the DLL.
I also tried to make the header file visible to the DLL and set a #include "myfile.h" in the DLL but this does not work.
|
|
|
|
|
I'm assuming you're getting compile time errors when compiling the DLL.
Please post the error messages and the relevant code.
|
|
|
|
|
Superman,
Please see the code posted to Albert Thread.
kind regards.
|
|
|
|
|
If you're going to pass by reference, your recipient (the DLL) needs the definition of what's enclosed, so it'll need the header file anyway. Just make sure it gets included into the DLL project as well.
|
|
|
|
|
Hello Albert,
Many thanks for your help.
Actually my problem is a linking issue.
with this message:
error LNK2019: unresolved external symbol "public: double __thiscall TestRef::unDouble(double)" (?unDouble@TestRef@@QAENN@Z) referenced in function "public: void __thiscall ClassRef::setval(int)" (?setval@ClassRef@@QAEXH@Z) MYDLL.obj
fatal error LNK1120: 1 unresolved externals Debug/MYDLL.dll
My Dll function has a pointer as parameter and the pointer calls the function member of the application's class and that function uses an object of another class of the application.
Could you please tell me how to solve it?
Below is the sample source of the DLL function
#include "classref.h" // file header of the application using the DLL
extern "C" __declspec(dllexport) int MainEntry( ClassRef* pRef )
{
int XX = pRef->entier;
XX = pRef->setval(5);
return 0;
}
And below is definition of setval(int )
void setval( int val)
{
double dbl = m_ref->unDouble(16.45); entier = val * dbl ;
}
|
|
|
|
|
Your error is telling you that that code was never compiled, did you add the header and cpp of "classref.h" to your DLL project?
|
|
|
|
|
Sure I tried the header alone and the cpp. with the header but linking message is still here.
I noticed a curious behavior as following:
1. If I put a comment on the function setval from within my Dll. Then it builds correctly
2. if I remove the comment and I just compile. This works fine as well.
3. Finally if I rebuild the DLL I get the linking errors.
|
|
|
|
|
I have got the reason of the problem.
Implementation and definition must be in the same file. I.e in the header.
But this brings to another problem that is the source code will be disclosed if the application is distributed.
|
|
|
|
|
It doesn't have to be in the same file, you just have to include both in your DLL project. As far as the source requiring to be disclosed.... well, don't pass an entire class to your DLL and you won't have to disclose the code. You should probably only pass data along. Make use of data structures instead of passing classes.
|
|
|
|
|
Presumably this is data that the dll does in fact know about.
If so the dll should provide a way to specify that data. So you use that.
If the dll doesn't provide such a way, then you must modify the dll to do that.
|
|
|
|
|
test all cases to check if can dead-lock?
But some case does not re-happen.
Is anyother quick way to do it ?
|
|
|
|
|
Ensure you have proper synchronization between threads when you need it, if it happened once and you did nothing to address the problem, odds are it'll show up again later on. Thread problems can show up differently from processor to processor, since the timing allocated to each thread can be different (on top of different speed/architecture), so make sure you synchronize properly.
I don't think there's any easy or quick way to check for race conditions.
|
|
|
|
|
Hi ,
I am working on an application which involves socket communication. Current in my read () function 'recv()' method is blocking, i.e. does not allow execution until it gets some data.
Here at this point I want to gracfully stop application . Is there any API for this ?
|
|
|
|
|
You have two obvious choices (and maybe a few more esoteric ones).
1. Google "non-blocking socket" and see how you can get to read what data is available, when you want to get it.
2. Fire up another thread which can block on the recv() call, but doesn't block your whole app. Another thread can then take control and shut down or whatever you need to do.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
I remember way back when me and my buddy were at the university and had a class about networking. The class got an assignment to make a simple chat program with 2 participants using sockets. At that point we never heard of non-blocking sockets before (not sure about threads). So most people made chat programs in which the two sides could talk alternately, A sending something, then B sending, then A again, then B and so on. We on the other hand, created a "ping-pong" mechanism, a kind of "token" packet would be sent here and there between the two clients constantly, if one had something to say, it would send its content along with the token to the other client, if it had nothing to say then it would just send the token alone back. This way the clients didn't seem to block waiting for the other side to say something. Ah, the good old naive young days...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
recv() is acting on Socket S.
Keep S in a list (or some other available source).
On shutdown spin up a thread. Grab S. Close S.
Then recv() will return. Modify the code that uses that to behave correctly.
|
|
|
|
|
Thanks all. I have implemented closesocket()option successfully
|
|
|
|