good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
Help designing a threaded serviceby Tommy (Chaplain) |
on Jan 23, 2014 at 23:52 UTC ( [id://1071853]=perlquestion: print w/replies, xml ) | Need Help?? |
Tommy has asked for the wisdom of the Perl Monks concerning the following question: I've envisioned a design for a listening service at $work that I'd like to implement, but I'm not sure how to do it right. I've iterated over it in my head, but I'm not sure if my ideas are the best approaches. I'm asking for some feedback. First let's start with what I'd like to accomplish:
The threading comes in now: I need the service to be able to process at least 20 connections in parallel, without making clients wait for a turn to run their command. I need a supervisor thread to monitor run times for all tasks and kill them off if they haven't been checked on in $timeout seconds. The classic supervisor-worker thread model might not work here, which is where I'm stumped. I'd have to have three types of threads, not two: 1) the supervisor, 2) the task runners, 3) the listeners. Why not forks? I don't want to use forks, because I need each listening thread to be able to know about all running tasks via threads::shared in-memory variables (I'm not going to be using a database to keep track of running tasks). I've recently gained a new respect for threading in Perl since my success with it in the recent DFW.pm hackathon, and I'd like to use those lessons learned in order to achieve success in this next endeavor. What do you think?
Tommy A mistake can be valuable or costly, depending on how faithfully you pursue correction
Back to
Seekers of Perl Wisdom
|
|