eaburns / T / 1055
87%
master: 88%

LAST BUILD BRANCH: gofont
DEFAULT BRANCH: master
Ran
Jobs 1
Files 9
Run time 0s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
1055

push

travis-ci

eaburns 
editor: finer-grained locking in the server.

Switch to RWMutex, and release locks early instead of hanging onto them for the entire handler.

Locking is generally straight-forward: rlock something before reading it; wlock something before writing it. However, there is one tricky spot: closing buffers. We need to make sure that we never close a buffer that is about to be used.

Here's how it works:

Routines using buffers call getBufferRLocked or getBufferLocked to get a RLocked or (W)Locked buffer respectively. In both cases, the buffer is found and locked _with the server RLock held_. This means that they were certainly on (and not removed from) from server's buffer's list when they were locked.

Closing a buffer happens in two steps: 1) remove the buffer from the server's buffer list with the server lock held. 2) lock the buffer and close it. When using getBuffer(R)Locked, either the buffer is not found, or it is found and cannot be closed until after the caller unlocks it.

There are three cases:
 a. Close 1; Close 2; getBuffer(R)Locked
    getBuffer(R)Locked doesn't find the buffer and returns not found.

 b. getBuffer(R)Locked; Close 1; Close 2
    Close 2 blocks until the returned buffer is (R)Unlocked.

 c. Close 1; getBuffer(R)Locked | Close 2
    getBuffer(R)Locked may happen concurrently with Close 2, because Close 2 doesn't hold the server lock. Regardless, the buffer is already removed from from the list, so getBuffer(R)Locked will return not found.

2500 of 2656 relevant lines covered (94.13%)

0.94 hits per line

Jobs
ID Job ID Ran Files Coverage
1 1055.1 (PATH=$HOME/gopath/bin:$PATH) 0
94.13
 Travis Job 1055.1
Source Files on build 1055
Detailed source file information is not available for this build.