Re: [asio-users] Multiple tcp acceptor in one program.
Brought to you by:
chris_kohlhoff
From: Igor R <boo...@gm...> - 2016-01-05 19:37:35
|
> If my handlers always use their own resources there will be no problems and I > can gain performance and scalability, is that right? Yes. > Here is a portion the code: http://codepad.org/oeFITS4v > It is a server that receives a command string from client, executes the > command then writes the output back (I removed ASIO_DISABLE_THREADS) > > The on_read handler uses read_buffer_ and the on_write handler uses > write_buffer_, I think this is safe enough. It looks ok. > Basically when a client sends a request to the server, session parses it and > creates a object (request class), request class has a method called execute(). > When multiple threads call the request::execute() it may be unsafe. > So I have two options: > - Create a global strand and wrap the execute() function of any connected > session, is it acceptable? Saying: 500 clients and wrap 500 functions, sharing > one database connection. <...> > - The data source is a MySQL server, I can let each session have its own db > connection, and I will try to assure that my application doesn't have any > shared data to be used concurently, each session is on its own and mysql > connector library is thread-safe already. The both ways will ensure thread-safety, but both of them create dependency between the networking module scalability/performance and some other i/o, which might be much slower, due to its nature. Imagine what will happen is a DB-related operation takes a lot of time or even gets stuck... Perhaps it would be much more convenient to create a dedicated io_service (or an "active object" encapsulating io_service), whose sole purpose is to process db-related tasks. Then, your networking module will just post() to that io_service functors that perform suck tasks when invoked (use std::bind or lambdas to create them). I assume that such a task may be executed asynchronously, in a "fire and forget" manner. If the initiator needs the result of the task execution, the things get more complicated... |