ATL / WTL / STL

Re: use of beginthreadex()

28-Nov-13 10:08

Hello,
Re:

Quote:
You may find it easier to run your separate thread as pure procedural code rather than as classes. But that will, of course, depend on what the code is actually doing.

I have been thinking about that quite a bit. It would probably be easier to start the process as a single procedure not wrapped up in a class. But, this is for TCP/IP and there is quite a lot to do. I suppose everything could be free standing functions, but that would require a single monster procedure or require a flock of arguments for every call.

Being a single person software team where I work has some advantages, but they are truly overwhelmed by the disadvantage of not having anyone to discuss ideas with.

I think I will go to a single simple function to test out the concepts and try to get some events working. Then I will return to the TCP/IP part of this. Working one problem area at a time will make this easier.

Thank you for your thoughts.

EDIT: I have worked this on and off through the day. The current status is that creating a simple thread with some events using a free standing procedure is easier than I thought and easier that it looks. Putting a TCP/IP manager in a single procedure would probably get ugly. Right now my next step is to see what it takes to put this one procedure in a class and start it as a thread.

Would this be worth writing up as a series of articles? Article 1: Simple thread, 2: Thread from a class, 3: TCP/IP as a separate thread.

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

modified 28-Nov-13 23:21pm.

Albert Holguin11-Dec-13 5:01

Albert Holguin

11-Dec-13 5:01

If you find it helpful, odds are somebody else will as well. With that said, there are a ton of threading and tcp/ip articles, so browse through them to make sure you're not just rewriting an article that's already been written.

When you say: "thread from a class", what do you mean? There is an MFC class called CWinThread that allows you to make an entire class that is it's own thread, including the messaging pump required to communicate with it without a separate mutex/critical section (although usually you end up using a combination of messaging and mutexes anyway).

easy for classes

bkelly1311-Dec-13 12:27

11-Dec-13 12:27

I used the phrase of start a thread from a class to indicate that a particular class, such as a TCP/IP manager class, be started as a separate thread from the main app. It turns out there are some difficulties and while relatively simple to execute, I find the code difficult to read. In particular the solutions I found have a difficult to fathom pointer cast and must have a static function used to fire it off.

HOWEVER: I just discovered a way to completely bypass that problem. Begin with the class, which of course has a single method, call it main_method() that will loop as needed and not exit until the purpose is complete. Then write a simple free standing procedure. All that procedure does is instantiate the class then call main_method(). It takes one line to instantiate the class and one to call the method. When the method returns, the next line of code deletes the class and one more calls _endthreadex() to formally end the thread. That is really trivial but none of the articles I read about present this concept. (And yes, this completely ignores communications between the thread and the main app, but that is also not so difficult.)

Does anyone know of any disadvantage to this?

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Re: easy for classes

Albert Holguin12-Dec-13 4:09

Albert Holguin

12-Dec-13 4:09

There are some simple issues with using _endthreadex() and in a typical worker thread you don't even have to call it explicitly but in any case... I don't quite see why doing all this is beneficial. Maybe if you posted some of the code for reference I could give you some better feedback.

Re: easy for classes

bkelly1312-Dec-13 12:53

I want to showing "+" allways in WTL CTreeViewCtrl

12-Dec-13 12:53

My application is to process telemetry data and send it to a display device. The band width is high so the TCP/IP manager will be in a separate thread. To my knowledge I have this figured out now. The function that instantiates the class and calls it also calls endthreadex() when the class exits. Quite simple now.

But if you say there are issues with using _endthreadex() I would like to hear about them.

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Re: easy for classes

Albert Holguin12-Dec-13 13:10

Albert Holguin

12-Dec-13 13:10

Well if anything is waiting on the thread handle, it's going to wait forever (or until it times out) because the thread handle doesn't get dealt with properly, but that would only be an issue if you were waiting on the handle (or if another unsuspecting programmer waits on your thread handle).

Typically the proper way of ending a thread is to have it end itself. In the case of a socket handling thread, you can have something to signal an end to the capturing process. If your thread is in a blocking recv() call, closing your socket will trigger a return.

From MSDN:

Quote:
Like the Win32 ExitThread API, _endthreadex does not close the thread handle.

cheng84977cc25-Nov-13 5:40

cheng84977cc

25-Nov-13 5:40

I have a file tree.I want to showing "+" allways,no matter current node has child node.In my initialization，i do this:

C++

TV_INSERTSTRUCT tvinsert;
tvinsert.hParent = item;
tvinsert.hInsertAfter = TVI_LAST;
tvinsert.item.mask = TVIF_TEXT|TVIF_CHILDREN;
tvinsert.item.cChildren=1;
tvinsert.item.pszText = (LPWSTR)(wstrFileName.c_str());
CTreeItem tmpItem = m_OrginazitionTree.InsertItem(&tvinsert);

And then it run. But I find a trouble,if current node don't hava child node,When I click it the current node "+" don't disappear.I want when the app initialization all node has "+" no matter node has child node,when I click one of tree node,if current node don't have child node,then this current node "+" will disappear.But this trouble I can't fix it.Is someone can help me ?thank you all your help.

PS:I don't use MFC,I just use CTreeViewCtrl in win32.

Re: I want to showing "+" allways in WTL CTreeViewCtrl

Wayne.CN13-Jan-14 17:51

Wayne.CN

13-Jan-14 17:51

Why all that? You can take the '+' as a icon.

[How to Convert data in textBox to .Txt file in Windows Form C++]

Member 1041578020-Nov-13 19:53

Member 10415780

20-Nov-13 19:53

Hello Guys, I want make a some data via Windows Form using C++ Visual Studio 2010 when if I enter into textBox the string can convert tobe Txt file...
I have problem about it...
Please Help me D'Oh! | :doh:

Re: [How to Convert data in textBox to .Txt file in Windows Form C++]

Richard MacCutchan20-Nov-13 22:21

waiting on events for socket activity

20-Nov-13 22:21

Member 10415780 wrote:
I have problem about it

What problem? Are you using pure Win32, MFC or WTL? Where do you want to save the text? Please give proper details of what you are doing and what does not work.

Veni, vidi, abiit domum

stl thread safe

G.aius.CodeCreator18-Nov-13 15:38

G.aius.CodeCreator

18-Nov-13 15:38

template<typename Container>
class Lock {
public:
    // have been omitted
    Lock(const Container& container)
        : c(container){
            getMutexFor(c);
    }

    ~Lock() {
        releaseMutexFor(c);
    }
private:
    const Container& c;
};

How to realize the releaseMutexFor and getMutexFor?

bkelly1318-Nov-13 14:05

18-Nov-13 14:05

Windows 7, visual studio 2008, C++
Reference: http://www.winsocketdotnetworkprogramming.com/[^]

I just discovered this site and now I think that a TPC/IP class can be created that does not use messages and needs no window. Async socket operation can generate events such as FD_SEND (it is okay to send now) and FD_READ (Windows has received some data for the application to capture.)

I can also declare and generate my own events. If I put the TCP/IP code in a class, make it a thread and crank it up, I can also pass it handles of events I have created along with the some other goodies in a single structure (such as the address of the buffer where the main app puts data to send out).

One of the key calls is WSAWaitForMultipleEvents() function where one of the arguments is an array of event handles. I did not recognize anything that places a limit on the type or category of events that it can received. (Is there any such thing as that? I know that Windows reserves event numbers below a certain value.)

Rather than a long post I will hope that the knowledgeable reader will recognize the intent and comment on the feasibility and/or loop holes and gotchas that await.

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Orjan Westin19-Nov-13 23:03

Orjan Westin

19-Nov-13 23:03

This is perfectly feasible, and there's a good example at the WSAWaitForMultipleEvents[^] help page.

bkelly1325-Nov-13 16:08

25-Nov-13 16:08

OK, I am going that way, mostly, I think. After a bunch of searching I have found/concluded that the several version of WaitForMultiple[Event,Object] all wind up using this:

ASM

DWORD WINAPI WaitForMultipleObjects(
  _In_  DWORD nCount,
  _In_  const HANDLE *lpHandles,
  _In_  BOOL bWaitAll,
  _In_  DWORD dwMilliseconds  );

from this page: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).aspx[^]

If the other versions, specifically the WSA versions are wrappers, and my primary goal is speed (i.e. minimum overhead), then it seems I should use the most fundamental call. This looks just about as simple as it could be. I am coding up a simple bare-bones thread to test it out. I think I have that ready will start of the main app that will create the events that the thread waits on.

Do you foresee any problems with this?

Edit: My searches have not produced a clear distinction between wait for EVENT and wait for OBJECT. They appear to be synonyms. Is that correct?

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

modified 25-Nov-13 22:28pm.

Orjan Westin25-Nov-13 23:01

Orjan Westin

25-Nov-13 23:01

You'll need to implement a mechanism to shutdown and close the connected sockets if the client closes the connection (I used a WaitForSingleObject in the listening socket thread, with timeout 0 on each of the associated thread handles in turn, to see if it's still running, but it can be done in many other ways).

The WSA versions are wrappers around the WaitForSingleObject and WaitForMultipleObject, yes.

EVENT and OBJECT and HANDLE are effectively all the same thing - they are numerical identifiers that the system uses to look up internal things. In most cases . This means that you can wait on a thread handle (that identifier will be signaled when the thread terminates) for instance. There's a list of the things that can be waited on in the documentation.

Best of luck!

bkelly1326-Nov-13 8:07

What is the window argument in WSAAsyncSelect(...)

26-Nov-13 8:07

Very Cool. That helps. I shall sally forth into this new arena.
Thank you for taking the time to reply.

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

bkelly1310-Nov-13 15:59

Re: What is the window argument in WSAAsyncSelect(...)

10-Nov-13 15:59

I am trying to figure out async sockets with the WIN API functions. My learning activity is to create a light-weight and fast class that can be used almost anywhere (within Windows OS of course) to create a TCP/IP interface. I used CAsyncSockets, got it working, but it was too slow. Blocking TCP/IP is fast enough, but has some difficulties I want to circumvent with async code.. In this article:
Programming Windows TCP Sockets in C++ for the Beginner[^]

The author references this call to set the socket mode to asynchronous:

//Switch the socket to a non-blocking asynchronous one
int PASCAL WSAAsyncSelect(SOCKET,HWND,u_int,long);

The MSDN page says the second argument is a handle to the window that will receive the messages.
Some details: I want to create a class that can be instantiated to create a TCP/IP interface from an application without a window interface. Specifically, my application will fetch telemetry data from some hardware, no user interface required there, I have the function calls to get the data. My app will open a socket as the server. When a client connects, it will send telemetry data to the user. No “window” or other user interface. No console window or DOS cmd window required or wanted.
Question: What can be put in as argument 2 for WSAAsyncSelect(…) Here it is from the MSDN page:

int WSAAsyncSelect(
  _In_  SOCKET s,
  _In_  HWND hWnd,
  _In_  unsigned int wMsg,
  _In_  long lEvent
);

Possible answer: The author included this next:

#define MY_MESSAGE_NOTIFICATION      1048 //Custom notification message

//This is our message handler/window procedure
LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message) //handle the messages
    {
    case MY_MESSAGE_NOTIFICATION: //Is a message being sent?
…

It is not in the downloaded code and not described fully. Does this become the “window” passed in that argument?

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

modified 10-Nov-13 22:09pm.

Richard MacCutchan10-Nov-13 21:08

create a window for callbacks

10-Nov-13 21:08

The application in question must have a window in order to receive the messages; that is the way that Windows works. The example you have above is merely showing how to implement a user defined message. If the application requires no user interaction at all then it is not necessary to show the Window, but it must still be created.

Veni, vidi, abiit domum

bkelly1311-Nov-13 2:00

11-Nov-13 2:00

Some searches indicate that I can create a window just for the callback with something like:

hwnd = ::CreateWindowEx(...)

Then I use the above noted procedure to get those messages, identify the message, and call the appropriate method.

Am I getting close? Will it be that simple?

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Richard MacCutchan11-Nov-13 3:01

11-Nov-13 3:01

bkelly13 wrote:
Will it be that simple?

Pretty much, yes. You also need a message pump to dispatch the messages to your handler. I would suggest you create a basic Windows application from the Win32 app template that comes with Visual Studio, and then add your socket code to it. That will allow you to display information as the application proceeds, and also to use the debugger to trace things. Once you have everything working as you require you can hide the window in your release version.

Veni, vidi, abiit domum

bkelly1311-Nov-13 4:49

11-Nov-13 4:49

Hello,
RE:

Quote:
I would suggest you create a basic Windows application from the Win32 app template that comes with Visual Studio, and then add your socket code to it.

That puzzles me a bit. My end result for this code is a class that can be included in various projects as opposed to a stand alone application. I cannot see very far down this path yet so will this method yield the results I want? Will I be able to just simply instantiate the class in a new project and have all that is needed for a TCP/IP link with another application/computer?

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Richard MacCutchan11-Nov-13 6:33

11-Nov-13 6:33

bkelly13 wrote:
Will I be able to just simply instantiate the class in a new project and have all that is needed for a TCP/IP link with another application/computer?

Quite possibly, but you still need to get it working first. My suggestion was to create a simple application in which to build and test your class. Once you have it all working you can convert your class into a library which can be used by other people.

Veni, vidi, abiit domum

bkelly1311-Nov-13 8:33

11-Nov-13 8:33

OK, I am going down that path, but I still see two parallel but close roads to take.

1. Write my TCP/IP class and find the handle to the main application and pass that to the class for the WndProc method.

2. Create any type of app/template in Visual studio, create a TCP/IP class, and use the CreateWindowEx(...) to create a new window. Make that window hidden and use it only to catch the TCP/IP messages.

From my perspective the second makes much more sense. If I create a new window from within the TCP/IP class then it does not need to capture message from the main app, or alternative, the main app does not need to tell the class about the messages received.

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Richard MacCutchan11-Nov-13 22:37