07:37:34 GMT <minus> solrize: but then you'll have to deal with locking
07:39:06 GMT <solrize> minus, yeah but that can't be as bad as the IPC that redis clients have to use now.  and if it's a single client no locks needed.  also it might be possible to use persistent data structures to eliminate locks though that would cause memory bloat and probably a speed hit
07:39:33 GMT <solrize> did you see the thing further up where someone tried a multi-threaded c++ version of redis?
07:53:34 GMT <minus> just now, yeah
08:02:40 GMT <solrize> i don't know how it deals with locking issues
08:03:12 GMT <solrize> the framework looks interesting, node-like callbacks within individual threads, and erlang-like isolation and message passing between threads
08:06:07 GMT <solrize> anyway gnite it's late here.  wish this channel was more lively sometimes.
21:11:58 GMT <solrize> minus, https://www.cs.cmu.edu/~hl/papers/mica-nsdi2014.pdf
21:12:15 GMT <minus> what's that?
21:12:30 GMT <solrize> it's a paper about another sort-of-redis like multicore thing
21:12:56 GMT <solrize> seems to have a user space network stack
21:12:59 GMT <solrize> like dpdk i guess
21:13:08 GMT <minus> crazy
21:13:28 GMT <solrize> seastar uses dpdk and says they get a big speedup
21:13:33 GMT <minus> downloading at 20KB/s, nice…
21:13:55 GMT <nonconvergent> I'm a little new to redis. Can I tell you what i want and you tell me how to structure it?
21:14:20 GMT <solrize> um ask
21:14:50 GMT <minus> heh, 'Mops'
21:15:47 GMT <minus> that looks like a fun paper to work on
21:16:05 GMT <nonconvergent> I'm trying to make a user data cache for incoming requests to account for the fact that some of the external resources I need to fill that data are unreliable. There's a couple fields for each user I want to cache, and I'd like to be able to pull and update them in parallel.
21:16:36 GMT <nonconvergent> So I can't just put, AFAIK, a user and his fields into a single hash keyed off the username
21:16:59 GMT <solrize> you want to get several fields atomically
21:17:11 GMT <solrize> you don't want to encode them into a single value, say as a json string
21:17:42 GMT <solrize> so you can use a transaction on the client side, or a lua script on the redis side
21:18:23 GMT <minus> did you read the whole paper, solrize?
21:19:00 GMT <solrize> not much... actually it's just a k-v store rather than one with nice data structures like redis
21:19:05 GMT <solrize> looking at it now
21:19:26 GMT <minus> yeah, that's what i expected
21:19:40 GMT <nonconvergent> Yeah, so lets say every username has the fields foo, bar, and baz. I'd like to spawn several actors to pull and if necessary update their values, concurrently.
21:20:10 GMT <solrize> spawn several actors?
21:20:28 GMT <solrize> like separate requests for foo, bar, and baz?
21:20:33 GMT <nonconvergent> solrize: Actor Model...a way of handling concurrency.
21:20:46 GMT <solrize> well what's happening concurrently?
21:21:42 GMT <solrize> anyway it usually ends up simple to just put a json string into the k-v store, like {"name":"bob", "address":"123 main street", etc }
21:21:58 GMT <solrize> i have an errand in a minute will be back later
21:22:07 GMT <nonconvergent> user "jeff" is getting his field foo, bar, and baz pulled out of the redis cache concurrently. So three actors will pull and if necessary first update if the field DNE, concurrently.
21:22:44 GMT <nonconvergent> Because each field is sourced from a separate external resource, and I don't want to wait.
21:22:56 GMT <nonconvergent> Any more than I have to
21:23:10 GMT <solrize> i see, so you want separate stores for foo, bar, and baz
21:23:12 GMT <solrize> that's ok
21:23:20 GMT <solrize> either use transactions or lua
21:23:29 GMT <solrize> i gotta go, bbl
21:24:34 GMT <nonconvergent> Transactions would handle it? Is that better than just using 3 hashes, with the key being "jeff_foo" and field "foo", "jeff_bar" and field "bar", etc?
21:25:22 GMT <nonconvergent> ...yeah, no redis transactions are sequential. That defeats the whole point.