Newest at the top
| 2025-06-23 13:03:19 +0200 | <Maxdamantus> | if it's the latter, then that's exactly what a read-write lock is. |
| 2025-06-23 13:03:12 +0200 | <[exa]> | so there's a whole lock hierarchy, the actual top is kinda compare-and-swapped very rarely by the writers |
| 2025-06-23 13:03:11 +0200 | <Maxdamantus> | actually, I guess there could be a wording issue here. when you say single writer, are you saying your code is already guaranteed to only write from one thread, or are you saying that the datastructure must enforce that? |
| 2025-06-23 13:02:40 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 244 seconds) |
| 2025-06-23 13:02:19 +0200 | <[exa]> | it's for a store of inverted indices, kinda like lucene segments |
| 2025-06-23 13:01:55 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 276 seconds) |
| 2025-06-23 13:01:54 +0200 | <Maxdamantus> | (though again, a read-write lock is theoretically more general, since it allows multiple writers) |
| 2025-06-23 13:01:48 +0200 | jespada | (~jespada@r179-25-124-186.dialup.adsl.anteldata.net.uy) jespada |
| 2025-06-23 13:01:24 +0200 | <Maxdamantus> | Well, if you don't want a queue, I guess what you want is just a read-write lock. |
| 2025-06-23 13:00:56 +0200 | <[exa]> | doesn't fit totally but so far closest :D |
| 2025-06-23 13:00:47 +0200 | <[exa]> | anyway yeah I guess that's exactly what I wasn't able to recall |
| 2025-06-23 13:00:06 +0200 | <[exa]> | *communication |
| 2025-06-23 13:00:02 +0200 | <[exa]> | but that's more like for communion channel kind of things, right? |
| 2025-06-23 12:59:55 +0200 | <Maxdamantus> | multi-producer single-consumer, multi-producer multi-consumer |
| 2025-06-23 12:59:36 +0200 | <[exa]> | oh producer and consumer |
| 2025-06-23 12:59:34 +0200 | <Maxdamantus> | producer, consumer |
| 2025-06-23 12:59:28 +0200 | <[exa]> | what does 'p' and 'c' stand for there? |
| 2025-06-23 12:59:07 +0200 | <Maxdamantus> | I guess "mpmc" covers the use case, but that's more general than what you're asking for. |
| 2025-06-23 12:58:38 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-06-23 12:58:12 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-06-23 12:57:42 +0200 | <Maxdamantus> | actually, maybe that doesn't exist. I kind of assumed it did, since there is "mpsc" in std. |
| 2025-06-23 12:56:28 +0200 | <Maxdamantus> | as opposed to "mpsc". |
| 2025-06-23 12:56:21 +0200 | <Maxdamantus> | [exa]: in Rust I think I've seen it called "mcsp", or maybe it was "spmc". |
| 2025-06-23 12:55:46 +0200 | prdak | (~Thunderbi@user/prdak) prdak |
| 2025-06-23 12:52:05 +0200 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-06-23 12:50:25 +0200 | <[exa]> | doubles nicely with "simple" and "complex" |
| 2025-06-23 12:50:10 +0200 | <[exa]> | whatevs, I'll mark them SW and CW like serialized writer and concurrent writer |
| 2025-06-23 12:48:57 +0200 | <[exa]> | (I've got 2 variants of a segmented data structure here, with the many-writer having a more complex locking scheme and way more overhead) |
| 2025-06-23 12:47:41 +0200 | <[exa]> | likely |
| 2025-06-23 12:47:34 +0200 | <__monty__> | Is this one of those elementary things that never got named successfully? |
| 2025-06-23 12:47:26 +0200 | tmciver | (~tim@syn-198-255-177-240.res.spectrum.com) tmciver |
| 2025-06-23 12:47:20 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-06-23 12:46:30 +0200 | tmciver | (~tim@syn-198-255-177-240.res.spectrum.com) (Ping timeout: 244 seconds) |
| 2025-06-23 12:45:48 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-06-23 12:45:36 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-06-23 12:45:16 +0200 | <[exa]> | is there some common coined name for data structures that allow concurrent access for many readers but only a single writer (ie. all writes have to be serialized)? |
| 2025-06-23 12:45:11 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-06-23 12:44:02 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2025-06-23 12:39:24 +0200 | talisc | (~talisc@user/talisc) talisc |
| 2025-06-23 12:34:49 +0200 | talisc | (~talisc@177.126.221.11) () |
| 2025-06-23 12:34:09 +0200 | talisc | (~talisc@177.126.221.11) |
| 2025-06-23 12:33:27 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 268 seconds) |
| 2025-06-23 12:33:05 +0200 | trickard_ | (~trickard@cpe-61-98-47-163.wireline.com.au) |
| 2025-06-23 12:32:51 +0200 | trickard | (~trickard@cpe-61-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-06-23 12:31:34 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 260 seconds) |
| 2025-06-23 12:30:24 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2025-06-23 12:29:00 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-06-23 12:28:51 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 276 seconds) |
| 2025-06-23 12:28:44 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds) |
| 2025-06-23 12:21:05 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |