/me nods...   If you do intend to do it that way, a few pointers I would suggest to thee:

• Let the thread that is doing I/O retrieve what it may retrieve and then place a frozen copy of the data onto a queue for further consumption.   It is unwise to try to be “efficient” about placing it into some shared buffer since this creates serious timing dependencies – and, likely as not, destroys the actual benefit of threading.
• Let there only be enough copies of the I/O thread to reasonably accommodate what I/O the computer can actually, reasonably do; and then, let those threads stick-around forever.   Build a queue for all of them to listen-to and another queue for all of them to post results back to.   If requests briefly “pile up” in those queues, then ... “So what.   That’s what queues are for.”   Such an arrangement is easily tunable and self-regulating.
• “Asynchronous I/O?”   Hmmmm, Might be useful, but might be more of a PITA than it pragmatically is worth, given that you’ve got a dedicated thread doing the I/O’s anyway.   Be mindful of how many requests might be up-in-the-air at any one moment, and of exactly what your hardware can reasonably be expected to do.   I/O requests usually don’t play well with others.   If a bunch of them are standing around, the room they’re standing around in gets awfully small, awfully quick.