[asio-users] Is async_result with Spawn Racy?

[Lee Clagett]

I was trying to use ASIO's async_result in another project, but ran into an
issue. In some situations I was trying to invoke the handler immediately,
instead of waiting on an operation. This resulted in an immediate
segmentation fault. A similar situation was described here [
https://github.com/BoostGSoC14/boost.http/issues/2 ]. The problem is that
the handler tries to switch the user-space thread to the user-space thread
currently in execution. Bjorn Reese fixed the issue by passing the handler
to io_service.post(), which meant the user-space thread was resumed on
another kernel-thread, after the user-space thread suspended on the current
kernel thread.

However, I think the io_service.post solution is still an issue. There
doesn't appear to be any synchronization inside of the async_result code
for boost::coroutine, so it should be possible for the handler to attempt a
switch to the user-space thread that is still executing on another kernel
thread. I think some synchronization object would have to be sent through
the boost::coroutine object itself, so that the handler would block until
the coroutine was properly suspended.

Lee

[Niall Douglas]

Post by Lee Clagett
However, I think the io_service.post solution is still an issue. There
doesn't appear to be any synchronization inside of the async_result code
for boost::coroutine, so it should be possible for the handler to attempt a
switch to the user-space thread that is still executing on another kernel
thread. I think some synchronization object would have to be sent through
the boost::coroutine object itself, so that the handler would block until
the coroutine was properly suspended.

This sounds like a bug, and fixing async_result for coroutines
desirable.

Though, that said, I can see qualms in this. On Windows Fibers you'd
test in the handler to see if you are already in the correct Fiber
and if so you would skip context switching because you can't block on
resuming yourself. I don't know if Boost Coroutine is the same.

Niall

[Yuri Timenkov]

Hi,


One thing could lead to this is that io_service::run() finishes before all work in spawned thread is done.

You could check this by looking at call stacks from other threads.

If it’s so then io_service::work may help preventing io_service from preliminary exit if you expect events coming from outside.


Regards,

Yuri






From: Lee Clagett
Sent: ‎Tuesday‎, ‎January‎ ‎6‎, ‎2015 ‎12‎:‎39‎ ‎AM
To: asio-***@lists.sourceforge.net







I was trying to use ASIO's async_result in another project, but ran into an issue. In some situations I was trying to invoke the handler immediately, instead of waiting on an operation. This resulted in an immediate segmentation fault. A similar situation was described here [ https://github.com/BoostGSoC14/boost.http/issues/2 ]. The problem is that the handler tries to switch the user-space thread to the user-space thread currently in execution. Bjorn Reese fixed the issue by passing the handler to io_service.post(), which meant the user-space thread was resumed on another kernel-thread, after the user-space thread suspended on the current kernel thread.


However, I think the io_service.post solution is still an issue. There doesn't appear to be any synchronization inside of the async_result code for boost::coroutine, so it should be possible for the handler to attempt a switch to the user-space thread that is still executing on another kernel thread. I think some synchronization object would have to be sent through the boost::coroutine object itself, so that the handler would block until the coroutine was properly suspended.


Lee