eaburns / T / 1057 / 1
87%
master: 88%

LAST BUILD BRANCH: gofont
DEFAULT BRANCH: master
Ran
Files 9
Run time 1s
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
coverage: 94.164% (+0.04%) from 94.127%
PATH=$HOME/gopath/bin:$PATH

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.

 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
    The buffer is already removed from from the list before getBuffer(R)Locked, so it will return not found.

2501 of 2656 relevant lines covered (94.16%)

0.94 hits per line

Source Files on job 1057.1 (PATH=$HOME/gopath/bin:$PATH)