|
Posted by Peter J. Holzer on March 31, 2008, 4:57 am
Please log in for more thread options
> I have a process I was thinking of making into a multithreaded daemon
^^^^^^^^^^^^^
> that deals with a MySQL database. The thought is that the daemon would
> open the database once, then listen for clients. As clients connected
> the daemon would fork off a copy of itself and handle the requests. This
^^^^
Do you want to use threads or fork?
> would make the process faster because I wouldn't need to open the
> database every time a new client wanted service.
This cannot be done. Not only will the database server get a mixture of
requests from different database clients on the same connection (this
could be solved), but it also has to send back all replies via the same
connection: Which client will receive the response? There is no way to
determine that.
(There is at least one RDBMS where the client automatically opens a new
connection when it detects a pid change - presumably the new connection
will be pre-authenticated and faster to establish).
Your best bet is probably to use a pre-forked approach like some web
servers. Run a number of your your daemons in parallel, all listening on
the same port. A client connecting to that port will get any of them.
If all are busy, the client has to wait, or a controlling process can
start more worker processes.
hp
| 
XML Sitemap