Using LWT for concurrency probably works for things like sockets; for files on spinning disks, it’s a little different., I fear. To wit, in order to get full throughput from a disk with movable head that has an elevator algorithm, you need to present enough IOPS to fill its queue. That’s very different than writing a block every time it’s ready-to-write. And the same is probably true on reading. Two different friends who wrote SAN systems, in C++ and Ocaml, both gave me the same solution: create a pool of C threads (real, kernel threads) that perform the I/O operations, and communicate with a main thread via either mutex/condvar/semaphores, or (better) loopback socketpairs.
Actually expressing your intentions to the hardware seems to be really important for disk drives. And this remains true, even after you factor in kernel-buffering. Because eventually you fill your kernel buffers. Or, heck, you might want to disable kernel-buffering,b/c that’s more copying, which gets in the way of performance.
I don’t know what the story is for SSDs, though. Everything I wrote above is for rotating disks with seeking heads.
If -all- you want to do is copy, probably forking processes to deal with reading and writing is going to be simpler than what I describe above.