|
There are several freeware products which can acomplish this. Couple of them are unlocker[^] and process explorer[^]. There is an article at codeproject as well showing how to acomplish this programtically but I can't seem to find it at the moment.
-Saurabh
|
|
|
|
|
Thank you. I downloaded unlocker and it does a good job.
modified 7-Mar-17 16:42pm.
|
|
|
|
|
Hi everybody,
this is my first post here so I hope I am in he correct board.
I am coding a little windows application that regularly get data from an http server (apache2 on linux). The application is coded in C++ and uses the wininet library to access internet.
My problem is that TCP connections closing do not seem to be clean. I am using InternetOpen() and InternetOpenUrl() synchronously. After I call InternetCloseHandle(), the connection state are:
-on the client: CLOSE_WAIT
-on the server: FIN_WAIT2
...and this lasts about one minute, which I guess is the default timeout for this state on the server.
Before I go more in the details of my implementation, could somebody confirm that this is not normal?
Many thanks in advance,
Smaon
modified on Monday, June 23, 2008 12:01 PM
|
|
|
|
|
Ok, here is an example program that illustrate my problem:
win32 console application.
#include "stdafx.h"
#include <wininet.h>
#include <string>
int _tmain(int argc, _TCHAR* argv[])
{
HINTERNET hInternet = InternetOpen((L"soper"), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL,0);
if ( !hInternet ){
return 0;
}
HINTERNET hConnection = InternetOpenUrl( hInternet, L"http://localhost/anypage.php", NULL, 0, INTERNET_FLAG_NO_CACHE_WRITE, 0 );
std::string result = "";
if ( hConnection )
{
CHAR buffer[1024];
DWORD dwRead;
while ( InternetReadFile( hConnection, buffer, 1023, &dwRead ) )
{
if ( dwRead == 0 )
break;
buffer[dwRead] = 0;
result += buffer;
}
}
printf("%s\n", result.c_str());
InternetCloseHandle( hConnection );
InternetCloseHandle( hInternet );
Sleep(30000);
return 0;
}
For the 30 seconds of the Sleep(), the connection remains in CLOSE_WAIT on the client side and FIN_WAIT2 on the server side. When the application exits, the connection is dropped. I don't think this is normal...
Smaon
|
|
|
|
|
|
Is it possible to set priority to the callback function?
Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Nope. (anyway, please, be more specific).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I thought, If possible I want to set high priority to callback which gets MIDI message and keep the MIDI message processing thread priority default(normal).
Otherwise, I need to set below_normal to processing thread.
Thanks for your help!!
Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
That way you only hit the target if the callback it's called by different thread.
BTW: Why do you need it?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi,
The callback get MIDI message and write into ring buffer after that it wakeup processing thread using event.
Sometimes when callback got more than one message, it writes in ring buffer and wakeup processing thread many times.
This time, If the callback is on writing a message from MIDI to ringbuffer and processing thread think this message is complete and reads by incrementing pointer.
If processing thread does it faster, it goes one byte beyond actual message(not complete) written by callback then callback get "buffer overrun" condition.
Thats why now, I made processing thread priority below normal and seems working.
Thanks,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
I think adjusting thread priority is not a reliable fix for the flaw on your syncrhonization mechanism.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi,
Me too think so, even though it seems working, It would be better If I fix it in some other proper way and not by just priority or timing.
Thanks & Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
I didn't fully understand what you were saying but I understood that the problem was because your buffer was accessed by two threads and you have problems when one is writing in it while the other is reading it (which is logical). If that's your problem, why don't you access the buffer in a critical section ? This way, only one thread will be able to access the buffer at a time and this will avoid having data corruption.
|
|
|
|
|
Hi,
I will try If I can use critical section.
Problem is data is written into a single ring buffer.
If I use critical section, then other thread cannot access any part of ring buffer until write finish.
I want to let other thread to read the messages written completely by write thread(callback) and not current message being written.
One way is, I can check write pointer location, if the message not complete, then reset the read pointer to current message starting byte and check for complete message again.
Thanks for your help, I will try this tomorrow in office and update after I fix it.
Thanks & Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Another option is to update the write pointer only when you have written your message completely.
|
|
|
|
|
Cedric Moonen wrote: Another option is to update the write pointer only when you have written your message completely.
Hi,
It is fixed now by your idea and there is no overrun.
Thanks for your great suggestion!!
Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Hi,
I am facing a problem while accessing values in a std::list in release build. The code I am using is like
struct _STRUCT_ABC
{
int iIdCount;
string szName;
}STRUCTABC, *PSTRUCTABC;
list<<PSTRUCTABC>>:: iterator ittr = g_ABCList.begin(); // g_ABCList is a golbal list with PSTRUCTABC
int iCount = ittr._Ptr->_Myval->iIdCount; // Works fine with _DEBUG prepocessor but does not work in release mode if _DEBUG prepocessor is not defined.
Now according to VS2005 compiler _Ptr is a private variable if _DEBUG is not defined. In that case how to access the values inside the list?
Thanks in advance.
|
|
|
|
|
Aryan S wrote: int iCount = ittr._Ptr->_Myval->iIdCount;
you don't like the public interface of the list (and its iterator), do you?
int iCount = ittr->iIdCount;
int iCount = (*ittr)->iIdCount;
[thanks to]
Cedric's post
[/thanks to]
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
modified on Monday, June 23, 2008 5:32 AM
|
|
|
|
|
What are you doing  ?
That's not the way to work with iterators. You hsould simply dereference them:
int iCount = (*ittr)->iIdCount;
|
|
|
|
|
Thanks!!!
I am actually new in this field... 
|
|
|
|
|
Aryan S wrote: I am actually new in this field...
There are a lot of tutorials on the web, it would be much more efficient to read some of them before going any further developing code with tools that you don't how to use.
Check this[^] for instance.
|
|
|
|
|
I have a few controls like button , list box and combo box on my dialog in a dialog based application. I use tab key to change focus on controls hence the OnkIllFocus for the controls is executed as i tab . But When i close the dialog OnkIllFocus for the last control having the focus is not executed.I want to know the reason why this happens .
I expect the current control having focus shud lose Focus on closing Dialog hence OnkIllFocus for that control shud be called.If i am wrong plz correct me.
|
|
|
|
|
Shaileshhex wrote: I want to know the reason why this happens .
Maybe because the WM_KILLFOCUS message is not generated at that point. Use Spy++ to verify.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hello, everybody. There is a such problem: it is impossible to process the 2-dimens. array, no problems arise when i allocate memory using malloc, but next lines of code brings computer to stop:
for(row=0; row<=2303; row++){
for(col=0; col<=3071; col++)
Arr[row][col]=....;
}
mmm..How solve this?
|
|
|
|
|
Rustik wrote: but next lines of code brings computer to stop
What do you mean ? Your computer really stops  ? Or your program just crashes ?
How is your array declared ? Are you sure you don't go outside the bounds of your array ? Remeber that C arrays are 0 indexed.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
