C / C++ / MFC

7-Apr-06 8:58

DavidCrow wrote:
He's using a DWORD which is four bytes.

Look again, the post was modified. In the original post, it said simply "word", not "DWORD".

DLL - Multithreading

borono7-Apr-06 5:40

7-Apr-06 5:40

Hello. I wrote a dll for use with a VB front-end. The DLL runs mainly in a while loop which takes full control over the one thread VB allows, which ultimately freezes the VB form. I was wondering if adding multi-threading to the DLL would help. Theorhetically, I would think that it might. For example, VB App loads DLL in one thread, DLL creates new thread for while loop processing, thus the VB form should be able to function.

Here would be an example of my DLL layout:

while() { // keep looping

for() {  // used for determining size of data being read

if () { // used to provide data parsing, misc.

} //end if
} //end for
} //end while

So, I suppose I would need to through the entire while loop in its own thread, but I have no idea how. I have never multithreaded before, so I would really appreciate an example, if possible.

I thank you in advance.

Richard Andrew x647-Apr-06 5:58

7-Apr-06 5:58

First, it would help if you specified what VB you are talking about, VB6 or .NET.

Second, it strikes me as extremely poor design to use a continuously looping thread. For such a thing, one usually uses a design that uses wait functions and alertable threads.

Why don't you describe what kind of processing the thread is actually doing, and I'm sure there is some way to redesign it so that it works better.

borono7-Apr-06 6:09

7-Apr-06 6:09

I am using VB6. As of now, the while loop is non-alertable, but will be before I am through. But, would be open to an example of that as well. However, that was an intention before the release. The thread is processing packet data as it comes off the wire. I need it to continously loop until user says stop.

let me know if you need more info. thanks in advance.

Richard Andrew x647-Apr-06 6:21

7-Apr-06 6:21

borono wrote:
The thread is processing packet data as it comes off the wire.

Well what do you mean by "the wire?" Is the thread talking directly to a device driver? Are you referring to TCP/IP sockets? There are numerous examples of how to accomplish overlapped I/O with TCP/IP sockets.

The theory with overlapped I/O, is that you create a worker thread that enters a wait state, waiting for data to arrive on one or more sockets. When the system alerts the thread that data has arrived, then the thread wakes up, and performs the necessary processing.

Just look up Overlapped IO in the MSDN. If you have questions about implementing it in your DLL, I and many others on this board can help you with that.

Rich

borono7-Apr-06 7:01

7-Apr-06 7:01

thats what I have now, the thread sits in a wait state waiting for data. I am talking directly to the device. I just can not stop it altogether at this point, without totally killing the process. I figure I can do this. I can create another vb project, solely to load my dll for capturing and that should work. However, I would rather do it properly with multiple threads.

How would I through the entire while loop in its own thread separate from the main thread, in my dll?

thanks in advance.

Richard Andrew x647-Apr-06 7:16

7-Apr-06 7:16

Well, the easy way out of your problem would be to call CreateThread in your DllMain function, so that your device polling happens on this second thread, and your main thread is free to return to the VB form.

DWORD ThreadId = 0;

HANDLE ThreadHandle = CreateThread( NULL, NULL, ProcessingFunction, lpParameter, NULL, &ThreadId );

Then your processing function would be declared as follows:

DWORD WINAPI ProcessingFunction(
  LPVOID lpParameter
);

Just put all your processing code into the ProcessingFunction, and you will have it running on a separate thread. But you will be responsible for communicating to the second thread when it needs to quit.

borono7-Apr-06 7:46

7-Apr-06 7:46

Oh no, now I am lost. Bare with me, I am currently sitting with two-ply jammed up both nostrils, sick as a dog, trying to keep up with you. Plus, this is all new knowledge to me, so I of course have questions.

With:

DWORD WINAPI ProcessingFunction(LPVOID lpParameter);

Would it go into my function:

char* _stdcall cap(char *adp) {

//place here

}

...?

Also, I don't have a DLLMAin function, because I thought it was not necessary when calling the DLL from VB. Is it alright to create one? Not sure how it looks.

Plus, doesn't the API cause leaks? I would rather avoid that, if possible. Doesn't look like I will be multi-threading anytime soon. So, here is another question, perhaps easier to explain. I also need to send the stats back to the VB app... how can I do that without sending a return, which ends the entire function. I just want to know how many protocols have been identified while capturing, without killing the entire thing. I'm not even going to guess, I have no idea what to do.

sorry for the slow comprhension rate today, I am normally quicker than this.

best regards

Richard Andrew x647-Apr-06 8:01

7-Apr-06 8:01

borono wrote:
Also, I don't have a DLLMAin function

Did you write this DLL? What language was used to write the DLL?

borono wrote:
Plus, doesn't the API cause leaks?

What kind of "leaks" are you talking about? And NO, the API by itself does not cause memory leaks.

If you want to create additional threads, you are going to have to use the Win32 API. I don't know of any way in VB6 to create additional threads.

borono wrote:
I also need to send the stats back to the VB app

For this, I would suggest looking up how to implement something called a "callback function" in your VB6 app. Then have the thread in your DLL periodically call the callback function with the necessary data.

Waldermort7-Apr-06 7:48

Waldermort

7-Apr-06 7:48

Hi Borono,

Sorry I didn't get chance to answer your E-mail yet. I was going to suggest running your dll in a thread, though it looks like you figured it out already. The only problems you may encounter is alerting the VB side about events happening in the thread.

I'm not sure how VB handles handles a message loop, or if there is one, but I would suggest creating a GetMessage() function in your dll which the VB can constantly call. Thus retrieving any notifications from the thread and acting on them.

borono7-Apr-06 8:27

7-Apr-06 8:27

thanks waldermort, that sounds like a good idea, GetMessage(). I actually tried using a separate function, which of course didn't work. I am trying. Yes, I think multi-threading is the answer here as well, I have a bit of research to do. thanks again and no worries about the email, I got up early today, am sick with nothing better to do and started stirring a bit, thought I would get going on it. Glad you jumped in. I think I am just upsetting the other gentlemen. Smile | :)

best regards

Richard Andrew x647-Apr-06 9:04

7-Apr-06 9:04

You were not upsetting me. I was already upset. Sorry if I came across gruff. Blush | :O

borono7-Apr-06 11:58

Alternative Shell for Windows

7-Apr-06 11:58

no problem my friend, no harm done. In fact, your suggestion on callbacks was quite successful. Just in case anyone needs the same, here is how you perform the callback from DLL to VB.

First you need to write the DLL. Create the new project, "simple project". Then paste this code:

 extern "C" void __stdcall TestCallback( void (*cb) (int*) )
{
        int nrMsg = 123 ;
        cb( &nrMsg );

}

Create a def file and place this in it:

LIBRARY MYDLLNAME

EXPORTS
TestCallback @1

Note: you have to do this for VB, also notice the _stdcall, again a must for VB.

Then compile the DLL and place in the VB project directory.

Create a new VB project and add a module and command button.

In module:

Option Explicit
'
Declare Sub TestCallback Lib "mydll.dll" (ByVal funcptr As Long)
'
Sub CallbackFunction(ByRef numb As Long)
    MsgBox "Success: " + Str(numb)
End Sub

In form:

Private sub Command1_Click()
TestCallback AddressOf CallbackFunction
end sub

Now compile the project and run. Should return 123.

gdlk, hope this was clear. now off to multi-threading. thanks

best regards

-- modified at 23:42 Friday 7th April, 2006

Update: multi-threading complete. I did what you said and it works great, can start and stop it at will now, easier than I thought it would be. thanks a lot.

this is solved, regards

Richard Andrew x647-Apr-06 5:15