To see the kind of stuff I'm talking about, take a look at https://github.com/jonhoo/flurry/pull/44#issuecomment-580368420 … (feel free to comment there).
-
-
Prikaži ovu nit
-
Conversation has moved to https://github.com/jonhoo/flurry/pull/48 … to avoid all the baggage from the various initial PR implementation discussion.
Prikaži ovu nit
Kraj razgovora
Novi razgovor -
-
-
Our codebase uses RwLock<HashMap> in a bunch of places where a concurrent hash map would be better (I didn't know about flurry). We want to run on embedded (including ESP32, which is multicore). So, no_std flurry would be really nice, but RwLock<HashMap> works decently.
-
In particular, there are a couple of (very occasionally written) registries, and one data structure that acts as a temporary database. Fortunately, we don't expect write loads to *ever* be on a critical path, so RwLock<HashMap> satisfies our needs.
- Još 1 odgovor
Novi razgovor -
-
-
the classic circumstance even on a simple single-processor would be from an interrupt context, though from there you also basically want to be lock-free there are other examples with task and preemption models, and multi-core (sometimes asymmetric) systems becoming more common
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
-
-
I read that no_std would be welcome when creating packages targetting operating systems, to install via package managers or built-in to the system ; there’s also the embedded community but concurrent is not usually what they’re after...
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.