Hi, In our application, inside the "main()" a tcp port made to listen, and the io_service is ran. It receives connection, and reads data from the connection. Then it create a thread and passes the "io_service" and the related "socket" as a reference to the new thread. Further communication are performed inside the thread. So far this works fine. Now inside the thread, I have created a "thread interruption point". This thread interruption point is inside a while loop for testing, and the while loop is inside the "async_read_handler". (That is the read handler never returns - When testing code is execution control is here-). By opening a new "telnet client", I have tried to connect to the listening port, it is connected, but the async_accept handler routine is not called! What could be the reason? How can I rectify this? Thanks, Lloyd ______________________________________ Scanned and protected by Email scanner
Now inside the thread, I have created a "thread interruption point". This thread interruption point is inside a while loop for testing, and the while loop is inside the "async_read_handler". (That is the read handler never returns - When testing code is execution control is here-). By opening a new "telnet client", I have tried to connect to the listening port, it is connected, but the async_accept handler routine is not called! What could be the reason? How can I rectify this?
Who calls async_read_handler? Check that the thread you're blocking (with "while" loop) is not supposed to pump the handlers, i.e. it's not the thread that executes io_service::run(). P.S. it's worth asking asio-related question on asio mailng list.
By debugging one thing I recognised is, io_service::run() is called from the main thread, and blocked thread is another one. But, in the blocked thread I have async_read() call handler. Inside the handler the thread is blocking. This is causing the problem. Now I will explain the real problem. There is a data write (to the disk) handler routine. If the disk is full I want the thread to wait until some disk space is free.For this what I do is, in the write handler there is a infinite while loop. Inside this thread interruption is enabled. The it checks for free space in the disk. If it is available, it breaks the while. Other wise it sleeps for some time, continues in the loop. Is there a better way to handle this? Thanks a lot, Lloyd ----- Original Message ----- From: "Igor R" <boost.lists@gmail.com> To: <boost-users@lists.boost.org> Sent: Wednesday, July 07, 2010 3:46 PM Subject: Re: [Boost-users] asio, new connection handler is not called
Now inside the thread, I have created a "thread interruption point". This> thread interruption point is inside a while loop for testing, and the while> loop is inside the "async_read_handler". (That is the read handler never> returns - When testing code is execution control is here-). By opening a new> "telnet client", I have tried to connect to the listening port, it is> connected, but the async_accept handler routine is not called! What could be> the reason? How can I rectify this? Who calls async_read_handler? Check that the thread you're blocking(with "while" loop) is not supposed to pump the handlers, i.e. it'snot the thread that executes io_service::run(). P.S. it's worth asking asio-related question on asio mailng list._______________________________________________Boost-users mailing listBoost-users@lists.boost.orghttp://lists.boost.org/mailman/listinfo.cgi/boost-users
______________________________________ Scanned and protected by Email scanner
De: Lloyd
Now I will explain the real problem. There is a data write (to the disk) handler routine. If the disk is full I want the thread to wait until some disk space is free.For this what I do is, in the write handler there is a infinite while loop. Inside this thread interruption is enabled. The it checks for free space in the disk. If it is available, it breaks the while. Other wise it sleeps for some time, continues in the loop. Is there a better way to handle this?
When the handler fails because of a disk full, it could, instead of entering a loop, schedule a timer and return immediately. When the timer fires, its handler would retry the write.
participants (3)
-
Eric MALENFANT -
Igor R -
Lloyd