|
SPowers wrote: a. I want to move the socket to its own thread so it has its own message pump.
See here and here.
"The largest fire starts but with the smallest spark." - David Crow
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
That answers a lot... I'm still a little confused how I can write to a buffer within a thread and have another thread read from it.
Do I keep a pointer to the buffer within both threads and only read from the buffer when i pass a message from the socket thread saying that it is ready to be read?
|
|
|
|
|
This sounds like the reader/writer problem.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
what is the reader/writer problem?
Is my assumption correct?
|
|
|
|
|
SPowers wrote: what is the reader/writer problem?
See here.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Ok that makes sense....
So I should plan it like this:
Databuffers:
buffer A: w/mutex
holds image data for frame X
buffer B: w/mutex
holds image data for frame y
x & y are concurrent image frames
Thread 1: main prgrm (reading and displaying data from buffer)
will hold pointers to buffer A & B
Thread 2: Socket exists on this thread and will handle sending and receiving data from socket as well as writing data to the data buffers
will hold pointers to buffer A & B
I'll have to put a mutex on the shared buffers so that they dont access it concurrently. And the mutex permissions will switch between the two buffers so that Thread2 can write constantly and Thread1 can read constantly.
Sound like a plan or did I miss the whole point completely?
|
|
|
|
|
Quick question:
Will reading memory that is currently being written cause an error or will it simply cause a versioning problem.
I ask this only because whenever I'm ready to write a frame I just want to dump the buffer into an image and I dont really care much about any versioning concerns.
|
|
|
|
|
It means that a frame could contain half of one image and half of another...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
That would definately not be a problem (knock on wood). If it is I could always implement a double buffer with mutexes.
I still havnt really gotten an answer about the shared memory. Since I'm new to threads my guess would be that each thread would have a pointer to the same piece of memory. Is that correct?
|
|
|
|
|
SPowers wrote: each thread would have a pointer to the same piece of memory. Is that correct?
Yes, that would work. Each thread shares the same address space, so any thread can access any memory that the application owns.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I have one more question (I think)
http://flounder.com/detach.htm#Sockets shows me how to detach the socket and assign it to a thread.
How do I use the Message Pump within the thread to catch the onReceive()/onSend() Messages
-- modified at 14:45 Thursday 25th May, 2006
|
|
|
|
|
Sorry, can't help you there. I've never used MFC sockets - I always use the raw Win32 versions.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
The help files recommend that user messages be defined in the range WM_USER to 0x7fff, but opening the Resource Symbols dialog to create a new ID and letting it choose the value seems to work fine. Does anyone know if there is anything wrong with this?
Best Regards
Cliff Hatch
-- modified at 14:42 Wednesday 24th May, 2006
|
|
|
|
|
Cliff Hatch wrote: The help files recommend that user messages be defined in the range WM_USER to 0x7fff...
It should be WM_APP.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Depends on the usage. If you are defining a message that will only be used within the application, then use WM_APP. If the message is for a control that could be used in other apps the use WM_USER. If it is a message that is used to communicate between different modules then use ::RegisterWindowMessage().
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: If the message is for a control that could be used in other apps the use WM_USER.
WM_USER should not be used at it can conflict with messages that Microsoft uses. RegisterWindowMessage() is the safest/preferred method in any case.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Thanks guys.
I can see that there is a problem if messages conflict, but what's puzzling me is why does it matter what the value is so long as it is unique - and if I use the Resource Symbols dialog to create it, doesn't that guarantee uniqueness?
Is it a matter of standardisation and ease of maintenance perhaps?
Best Regards
Cliff
|
|
|
|
|
|
Thanks Michael, that answers my question perfectly. 
Best Regards
Cliff
|
|
|
|
|
I've created a handler for a user defined message with the following declaration:
afx_msg LRESULT OnIdleScan(WPARAM wPar, LPARAM lPar);
It works, but what value (of type LRESULT) should the function return, and what does the system do with this? I assume it is not passed back via PostMessage, because it doesn't wait for the handler to execute. I'm arbitrarily returning 0 at present.
Best Regards
Cliff Hatch
|
|
|
|
|
The result is not used for PostMessage()'s, but it is when using SendMessage(). The return value is completely up to you. I usually just return 0, if its not important.
I have come across a few messages that are used in this way to indicate success or failure.
I Dream of Absolute Zero
|
|
|
|
|
Thanks for your reply. It makes perfect sense now.
Best Regards
Cliff
|
|
|
|
|
I have read several sources on when to use the extern keyword and when not to, but I still have some confusion.
Could someone explain the proper use of extern when it comes to variables and function:
extern void MyFunction(void);<br />
extern int MyVariable;
Thanks.
|
|
|
|
|
masnu wrote: Could someone explain the proper use of extern when it comes to variables and function:
extern void MyFunction(void);
extern int MyVariable;
In both cases, it specifies external linkage (i.e., is visible from files other than the one in which it's defined).
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
you use extern when you want to tell the compiler the type of a variable or function which is defined in another file.
if you have a variable called blah, of type int, at global scope (not static, or local to a function) in foo.c and you want to use it in bar.c, you would put "extern int blah;" somewhere in bar.c, or in a file that bar.c includes. that way, when the compiler is working on bar.c, it knows the type of the variable 'blah'.
the linker will come around later and make sure all references to 'blah' are looking at the same thing.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
