I am looking for a simple way to read/write a file asynchronously using Win API. What I had is mind is something like the asynchronous winsock API (WSAxxx) completion routines. However the file API doesn't seem to have those. Are they hidden somewhere?
Waiting on the overlapped events in a seperate thread adds thread management overhead, not to mention there either needs to be a thread-per-file, or the 64 objects problem needs to be faced. Completion ports is an overkill. Reading the file synchronously on a seperate thread is irrelevant.
Any suggestions?
CreateFile and ReadFile/WriteFile functions support so-called 'overlapped' mode which is what you need. There' also ReadFileEx/WriteFileEx that work in async mode only.
In short, you need to open file with FILE_FLAG_OVERLAPPED flag and pass OVERLAPPED structure (and callback in case of xxxEx operations) to file access functions.
Here's a sample class for using it.
I know that in .net it's possible. What I don't know is to which win32 functions it maps
As soon as you step into the async territory you should forget the word "easiest"
Seriously, the easiest would be to use .NET's System.IO.FileStream with isAsync=true in constructor and BeginRead/EndRead methods.
Related
I'm researching into game anti-cheat solutions so I can get a better grasp at how such security works. An approach used by many cheats is to use OpenProcess to open a process handle so they can use ReadProcessMemory to directly read data:
var procHandle = Kernel32.OpenProcess(
ProcessAccessRights.MemoryRead,
false, process.Id
);
(snippet from a C# game cheat)
This can be used to, for example, retrieve the positions of various entities in the game world, without needing to inject any kind of DLL; cheats that use this approach are called "external" cheats (as opposed to "internal" cheats that inject a DLL into the process).
In my anti-cheat engine, I want to detect such operations. I haven't been able to find any WinAPI methods that would call any kind of callback when a new kernel process handle is opened. If such method doesn't exist, I'm willing to use polling and enumeration (go through every single process handle to see if it's referring to my game process, and if it has the PROCESS_VM_READ access right. However, I couldn't find a function to get all such handles as well.
I'm pretty sure anti-cheat engines like Valve Anti-Cheat or BattleEye use this kind of detection; so, I think this would be possible from user-mode, since VAC does not install any kind of kernel driver, from my knowledge. If that is also not possible, a notification to when ReadProcessMemory is called would also work, but I doubt that's possible.
Any reference to a WinAPI method in the documentation that can accomplish such task would be appreciated, or a snippet ( in any language that can use WinAPI, I don't really mind :) ) that would demonstrate such behavior.
I have implemented a Windows keyboard hook in Rust and would like to pass the data it reads to another process that can actually make use of the data. I tried creating a named pipe and having the callback function write the data to the pipe, but I've found there is a significant amount of overhead in that method. What methods would you suggest for passing data from keyboard hooks to another process?
I appreciate the suggestions. I implemented the mapped memory approach and found that was significantly faster than named pipes, but also more complicated from my perspective. I actually ended up falling back on the Windows messaging system and passed everything using PostMessageW, which was very simple and fast enough. Thanks a lot.
On Unix: I’ve been through FAM and Gamin, and both seem to provide a client/server file monitoring system. I would rather have a system where I tell the kernel to monitor some inodes and it pokes me back when events occur. Inotify looked promising at first on that side: inotify_init1 let me pass IN_NONBLOCK which in turn caused poll() to return directly. However I understood that I would have to call it regularly if I wanted to have news about the monitored files. Now I’m a bit short of ideas.
Is there something to monitor files asynchronously?
PS: I haven’t looked on Windows yet, but I would love to have some answers about it too.
As Celada says in the comments above, inotify and poll are the right way to do this.
Signals are not a mechanism for reasonable asynchronous programming -- and signal handlers are remarkably dangerous for the inexperienced and even for the experienced. One does not use them for such purposes voluntarily.
Instead, one should structure one's program around an event loop (see http://en.wikipedia.org/wiki/Event-driven_programming for an overall explanation) using poll, select, or some similar system call as the core of your program's event handling mechanism.
Alternatively, you can use threads, or threads plus an event loop.
However interesting are you answers, I am sorry but I can’t accept a mechanism based on blocking calls on poll or select, when the question states “asynchronously”, regardless of how deep it is hidden.
On the other hand, I found out that one could manage to run inotify asynchronously by passing to inotify_init1 the flag IN_NONBLOCK. Signals are not triggered as they would have with aio, and a read call that would block blocking would set errno to EWOULDBLOCK instead.
I am working on a program which is essentially single-threaded, and its only thread is the main event-loop thread. Consequently, all its data structures are basically not protected by anything like critical region.
Things work fine until it recently integrates some new functions based on DirectShow API. Some DirectShow APIs open a second event-loop and within that second loop it dispatch messages (i.e. invoke other event-handling callbacks unpredictably). So when a second event-handling function is invoked, it might damage the data struct which is being accessed by the function that invokes the DirectShow API.
I have some experience in kernel programming. And what comes in my mind is that, for a single-threaded program, how it should deal with its data structure is very like how kernel should deal with per-CPU data structure. And in kernel, when a function accesses per-CPU data, it must disable the interrupt (very like the message-dispatching in a second event-loop). However, I find there is no easy way to either avoid invoke DirectShow API or to prevent the create of a second event-loop within them, is there any way?
mutexes. semaphores. locking. whatever name you want to call it, that's what you need.
There are several possible solutions that come to mind, depending on exactly what's going wrong and your code:
Make sure your data structures are in a consistent state before calling any APIs that run a modal loop.
If that's not possible, you can use a simple boolean variable to protect the structure. If it's set, then simply abort any attempt to update it or queue the update for later. Another option is to abort the previous operation.
If the problem is user generated events, then disable the problematic menus or buttons while the operation is in progress. Alternatively, you could display a modal dialog.
I realise that I can't access Form controls from the DoWork event handler of a BackgroundWorker. (And if I try to, I get an Exception, as expected).
However, am I allowed to access other (custom) objects that exist on my Form?
For instance, I've created a "Settings" class and instantiated it in my Form and I seem to be able to read and write to its properties.
Is it just luck that this works?
What if I had a static class? Would I be able to access that safely?
#Engram:
You've got the gist of it - CrossThreadCalls are just a nice feature MS put into the .NET Framework to prevent the "bonehead" type of parallel programming mistakes. It can be overridden, as I'm guessing you've already found out, by setting the "AllowCrossThreadCalls" property on the class (and not on an instance of the class, e.g. set Label.AllowCrossThreadCalls and not lblMyLabel.AllowCrossThreadCalls).
But more importantly, you're right about the need to use some kind of locking mechanism. Whenever you have multiple threads of execution (be it threads, processes or whatever), you need to make sure that when you have one thread reading/writing to a variable, you probably don't want some other thread barging and changing that value under the feet of the first thread.
The .NET Framework actually provides several other mechanisms which might be more useful, depending on circumstances, than locking in code. The first is to use a Monitor class, which has the effect of locking a particular object. When you use this, other threads can continue to execute, as long as they don't try to lock that same object. Another very useful and common parallel-programming idea is the Mutex (or Semaphore). The Mutex is basically like a game of Capture the Flag between your threads. If one thread grabs the flag, no other threads can grab it until the first thread drops it. (A Semaphore is just like a Mutex, except that there can be more than one flag in a game.)
Obviously, none of these concepts will work in every particular problem - but having a few more tools to help you out might come in handy some day :)
You should communicate to the user interface through the ProgressChanged and RunWorkerCompleted events (and never the DoWork() method as you have noted).
In principle, you could call IsInvokeRequired, but the designers of the BackgroundWorker class created the ProgressChanged callback event for the purpose of updating UI elements.
[Note: BackgroundWorker events are not marshaled across AppDomain boundaries. Do not use a BackgroundWorker component to perform multithreaded operations in more than one AppDomain.]
MSDN Ref.
Ok, I've done some more research on this and I think have an answer. (Let the votes decide if I'm right!)
The answer is.. you can access any custom object that's in scope, however your access will not be thread-safe.
To ensure that it is thread-safe you should probably be using lock. The lock keyword prevents more than one thread executing a particular piece of code. (Subject to actually using it properly!)
The Cross Threading Exception that occurs when you try and access a Control is a safety mechanism designed especially for Controls. (It's easier and probably more efficient to get the user to make thread-safe calls then it is to design the controls themselves to be thread-safe).
You can't access controls that where created in one thread from another thread.
You can either use Settings class that you mentioned, or use InvokeRequired property and Invoke methods of control.
I suggest you look at the examples on those pages:
http://msdn.microsoft.com/en-us/library/ms171728.aspx
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.invokerequired.aspx