The problem there is Thread.Stop() doesn't reach down far enough into the kernel to grab the thread and throw the exception until the thread comes off the blocked ReadFile() call. Please no posts on this.) When you stop a. (Yes, I know "kill -9" unconditionally kills UNIX processes, and contained threads. This whole thing would never be an issue if you could actually "kill -9" the thread. What you are essentially doing is creating a custom asynchronous I/O operation. Have to be tested - consuming resources that should never have to be consumed. I have considered the option you mentioned, but again, this causes a thread of execution to kind-of sit and spin - going back to a test that should never
To answer your question about the device operation, yes, the device is synchronous in operation. If you use it, you are going to have to use some programmatic skill and slight-of-hand to get around the Windoz
MICROSOFT VISUAL STUDIO TPB WINDOWS
To make perfectly clear to the community, this means that synchronous I/O is not an effective means of communication in Windows pre-Vista. CancelSynchronousIo() is not available before Vista. The documentation on CancelIo() and CancelIoEx() system calls state that they only work on "overlapped" or asynchronous I/O. Please tell me that is not true in Windows, and provide a solution. Not being able to force a thread off a ReadFile() essentially makes synchronous I/O useless. Re-architecting a solution is not an answer. Please, no responses telling the community to use asynchronous or "overlapped" I/O. How do you cleanly close file handles when you have a thread purposefully blocked on a read? It's obvious that CloseFile() alone is NOT the answer. I just want the thread to come off the ReadFile() when I I'm not looking to reinvent the wheel or change a basic concept. Done all over the place in embedded software. Having separate threads blocked on a read is an elementary activity. The result is a locked-up application and consumed system resources - not good. The thread continues to sit on the ReadFile() until I physically disconnect the USB HID device. One would think that calls to CloseFile() with the appropriate handle would do the trick,īut no.
MICROSOFT VISUAL STUDIO TPB FREE
When I close my application, I want to free all open handles, get all blocked threads off the ReadFile() and kill them, do some basic clean-up and shutdown tidy. No having to deal with "Overlapping." or building in some extraneous loop and test. If it is a NULL message I know the device was physically removed. When a thread comes off the ReadFile(), I know I have a message. They sit there waiting for an input message. I created it that way because I want to have separate threads that sit on the read of my (multiple) USB It is blocked because that is the way I created the file handle using CreateFile(). I have a thread that is blocked on a ReadFile() call. I have seen a few posts on this subject but no definitive answer.
0 kommentar(er)
