|
Hello,
I have a point of confusion here. In response to my question you wrote:
Quote: No, it merely starts the thread at the address pointed to by start_address.
I concluded that CreateThread would not create an instance of the class, just start it running as a separate thread. From that I conclude I must instantiate the class then start it as a separate thread. If that is so then calls to that class would be in the same address space. If not, then why would I instantiate it before calling CreateThread?
In either case I don't know what will happen.
I had some difficulties with the code I was writing so I stripped it down to the bare bones of nothing more that being able to start a thread. I will be working with that in the meantime.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
As you say, CreateThread would not create an instance of the class. This function creates a new process which runs in parallel with the currently running code, starting at the address given. Within the new process you can create new objects of a class and run their methods, while other objects are actioned in the main thread. As I said before, there is no communication between the two processes except by passing information through shared memory. 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.
Veni, vidi, abiit domum
|
|
|
|
|
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.
|
|
|
|
|
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).
|
|
|
|
|
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/
|
|
|
|
|
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.
|
|
|
|
|
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/
|
|
|
|
|
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.
|
|
|
|
|
I have a file tree.I want to showing "+" allways,no matter current node has child node.In my initialization，i do this:
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.
|
|
|
|
|
Why all that? You can take the '+' as a icon.
|
|
|
|
|
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 
|
|
|
|
|
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
|
|
|
|
|
template<typename Container>
class Lock {
public:
Lock(const Container& container)
: c(container){
getMutexFor(c);
}
~Lock() {
releaseMutexFor(c);
}
private:
const Container& c;
};
How to realize the releaseMutexFor and getMutexFor?
|
|
|
|
|
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/
|
|
|
|
|
|
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:
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.
|
|
|
|
|
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!
|
|
|
|
|
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/
|
|
|
|
|
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:
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
LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case MY_MESSAGE_NOTIFICATION:
…
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.
|
|
|
|
|
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
|
|
|
|
|
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/
|
|
|
|
|
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
|
|
|
|
|
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/
|
|
|
|
|
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
|
|
|
|
|
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/
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
