Scheme Request For Implementation

[alexmiller]

@MMcM

by not exposing that the key-value store might be asynchronous

Ah, thank you, I had forgotten this part.

To pull from some wisdom previously left on our forums:

@KrzysFR

But after a while, I observed something strange: when dealing with a remote database (like fdb), all your reads are async, and all the “writes” (Set/Clear/Atomic) are non-blocking until you commit. With an embedded K/V Store that uses memory mapped files, this is exactly the reverse: reads are non-blocking (if the data file is already cached in memory) and writes are blocking (because I used single-writer so they needed to acquire a lock).

So to be conservative, you’d need to be async on reads, writes and commit.

Ideally, you’d be able to write code like

(define do-something (tr)
  (let ((a (okvs-get tr "a"))
        (b (okvs-get tr "b"))
        (c (okvs-get tr "c")))
    (+ (bytes->int a) (bytes->int b) (bytes->int c))) 

and the get of a, b, and c could be done in parallel.

This might eventually come down to how would a non-blocking version of this fit with whatever the event loop/framework constructions in scheme look like, and I have no idea what those are.

I had played around with using proxy objects in python once, which are potentially an option in dynamic languages, but I suspect that scheme wouldn’t be amenable to trying to teach (+) that if it gets something that is-okvs-future? that it needs to wait on it to turn itself into an int.