iconara / ione

100%

master: 99%

LAST BUILD ON BRANCH improve-base-connection-locks

branch: improve-base-connection-locks

CHANGE BRANCH

x

Reset

• improve-base-connection-locks
• 1.2.0.pre4
• acceptor-host-and-port
• after-factory
• byte-buffer-getbyte
• byte-buffer-index
• deprecate-future-value
• destructive-future-combinators
• fix-jruby-test-issues
• fix-warnings
• future_improvements
• handle_badf_in_select
• http_server
• io-reactor-drain
• master
• optimize-resolved-combine
• optimize_future_combinators
• optimized_scheduler
• restartable_reactor
• running-while-stopping
• ssl_support
• ssl_support_on_1.2
• stack-safe-after
• stack-safe-reduce
• streams
• synchronized_close
• thread-pooling
• travis-test
• travis_debug
• try-complete-promise
• unblock-once
• uncaught-error-handler
• v1.0.0
• v1.1.0
• v1.1.0.pre0
• v1.1.1
• v1.1.2
• v1.1.3
• v1.1.4
• v1.1.5
• v1.1.x
• v1.2.0.pre0
• v1.2.0.pre1
• v1.2.0.pre2
• v1.2.0.pre3
• v1.2.0.pre4
• v1.2.0.pre6
• v1.2.0.pre7
• v1.2.0.pre8
• v1.2.1
• v1.2.2
• v1.2.3
• v1.2.4
• v1.2.x
• v1.3.0.pre0
• v1.3.0.pre1
• v1.3.0.pre2

Build # 303

Build Type

push

travis-ci

Committed by iconara

Commit Message

Reduce lock duration for BaseConnection#flush

This avoids performing the nonblocking write while holding the lock.
While it seems counter-intuitive, it seems this operation frequently
takes a lot of time. I don't know whether it is due to a profiling
artifact or not, but it shouldn't hurt in any case.

Since reads from the write buffer only happen from the single reactor
thread, we could actually perform (some) flushes without locking before
performing the non-blocking write. This uses a new byte-buffer accessor
that allows peeking at the contents of the byte buffer without taking
any lock.

Run Details

2812 of 2816 relevant lines covered (99.86%)

19994.09 hits per line