Sorry. But I'll need more than that to go on. A description of the basic structure of the application at least.
For example, what would the methods that you wish to call from the 'other' threads do to the state of the object? How does that relate to what that other thread is doing? etc.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Note that you don't need to use threads to do that. You can use assynchronous IO. Take a look at POE, AnyEvent and IO::Async.
| [reply] |
/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.
| |
