Re: [asio-users] Multiple tcp acceptor in one program.

[Svante K. <sva...@cs...>]

>Perhaps it would be much more convenient to create a dedicated
>io_service

I make a tiny async postgres library using asio a couple of months ago as a
sample for someone.
https://github.com/bitbouncer/postgres-asio/tree/master/postgres_asio

Take a look at the async connect

void connect(std::string connect_string, on_connect_callback cb);

postgres has no async connect but it is implemented using a background
io_service which never blocks the foreground ioservice.

(What's missing from that library is a decent pooling of connections
otherwise it seems to work very well)


/svante

2016-01-05 20:36 GMT+01:00 Igor R <boo...@gm...>:

> > 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...
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> asio-users mailing list
> asi...@li...
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>