New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assertion failure for concurrent read and close calls on a single TCPConnection #1376

Closed
mzfhhhh opened this Issue Jan 19, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@mzfhhhh

mzfhhhh commented Jan 19, 2016

when client socket send msg or disconnect, this demo will crash.

shared static this()
{
    listenTCP(10000,(conn){

        auto td = runTask({
            ubyte [3] buf;
            conn.read(buf);
        });

               //td.join(); 
               //td.interrupt();             
        conn.close();        
    });
}
core.exception.AssertError@..\..\source\vibe\core\core.d(1191): Manually resumin
g task that is already scheduled to resumed.
----------------
0x0053F9C9 in _d_assert_msg
0x0041AABD in vibecorecoreVibeDriverCoreresumeTask at C:\Users\mzf\AppData\Roami
ng\dub\packages\vibe-d\examples\http_request\..\..\source\vibe\core\core.d(1185)

0x0041A8D8 in vibecorecoreVibeDriverCoreresumeTask at C:\Users\mzf\AppData\Roami
ng\dub\packages\vibe-d\examples\http_request\..\..\source\vibe\core\core.d(1161)

0x0043E85A in onSocketEvent at C:\Users\mzf\AppData\Roaming\dub\packages\vibe-d\
examples\http_request\..\..\source\vibe\core\drivers\libevent2_tcp.d(693)
There were still 2 tasks running at exit.

@s-ludwig s-ludwig closed this in bfdf1a8 Jan 27, 2016

@s-ludwig s-ludwig changed the title from is this a bug? to Assertion failure for concurrent read and close calls on a single TCPConnection Jan 27, 2016

@s-ludwig s-ludwig added the bug label Jan 27, 2016

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Jan 27, 2016

Member

Was indeed a bug. Now properly throws an Exception instead.

Member

s-ludwig commented Jan 27, 2016

Was indeed a bug. Now properly throws an Exception instead.

s-ludwig added a commit that referenced this issue Feb 26, 2016

Explictly avoid double-resumption of tasks during Libevent2TCPConnect…
…ion.close().

The previous fix for #1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order.

s-ludwig added a commit that referenced this issue Feb 27, 2016

Explictly avoid double-resumption of tasks during Libevent2TCPConnect…
…ion.close().

The previous fix for #1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order.

(cherry picked from commit 350130a)

machindertech added a commit to machindertechnologies/vibe.d that referenced this issue Feb 27, 2016

Explictly avoid double-resumption of tasks during Libevent2TCPConnect…
…ion.close().

The previous fix for #1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order.

(cherry picked from commit 350130a)

s-ludwig added a commit that referenced this issue Apr 10, 2016

Explictly avoid double-resumption of tasks during Libevent2TCPConnect…
…ion.close().

The previous fix for #1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order.

(cherry picked from commit 350130a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment