On Mon, 08 Dec 2014 17:44:09 GMT, yawniek wrote:
Thanks Etienne, very helpful hints.
i probably want your async branch as soon as i start to shard over multiple leveldb backends.
and yes indeed, leveldb does block. My benchmark inserts around 70M 128bit keys (no values) in 4M batches, when writing the batch it takes a few seconds. (4M was empirically the best batch size on my macbook, https://gist.github.com/yannick/b638cab9f76d845446da).not sure on how to handle reads though, is there a way to do blocking calls into Workers or do i need to send a struct with the sender and then reply?
maybe i go back to just having a fiber and then buffer writes within a decoupled server that also does the sharding.
I suggest sending a Tuple!(Tid, T), where Tid is the sender that is waiting for a reply. Although I think using an async API that supports yielding would be best. This would only require that you use the TCPConnection object for protocol queries.
I wouldn't recommend the async library directly unless you want to drop fibers and create a C-style library of callbacks ..:)