Ask a question #2

merged 3 commits into from Apr 11, 2012


None yet
2 participants

kezhuw commented Apr 10, 2012

Is there any case that ((struct socket *)s)->status was set to SOCKET_CLOSED, but s->node is not NULL ?

I think there is no chance that socket's node field get new value when its status is already set to CLOSED.
So in commit 5d2bba5, I didn't free socket's node field in mread_pull().

I don't think move "ringbuffer_free" to "_close_client" is right,

Because ringbuffer_collect has already clear the block list ( set blk->id to -1 ) .


kezhuw replied Apr 11, 2012

Your are right. Thanks.

It has not to reset the rb->head when EWOULDBLOCK , because the block not link to the list , so it can be used later. and we hardly got EWOULDBLOCK actually. (epoll tell the socket can be read first)

What's your idea ?


kezhuw replied Apr 11, 2012

This commit does several things:

  1. set newly allocated id to -1. So if client acquire it, but without using, ringbuffer can reuse it later.
  2. give back newly allocated block if we don't use it. I think ringbuffer is pleasure, when client do this.
  3. handle SOCKET_SUSPEND situation.

Resetting rb->head when EWOULDBLOCK conforms to point 2. Nothing about whether EWOULDBLOCK can happen.


cloudwu commented Apr 10, 2012

You are right about the status SOCKET_CLOSED .

cloudwu added a commit that referenced this pull request Apr 11, 2012

@cloudwu cloudwu merged commit b75b6d0 into cloudwu:master Apr 11, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment