trio.Barrier synchronization promitive

[ntninja]

Trying to fix an edge case in my implementation of a TeeingReceiveStream, I discovered that I likely need a task synchronization primitive called a “barrier” (Python threading docs) to synchronize value read access between different tasks.

Would this be considered a good fit for inclusion into trio? It not being present right now, I'll have to write my own, so what I'm really asking is: Should I bother polishing it up and hand it in for review or not?

– A big trio fan 🙂

[njsmith]

Would this be considered a good fit for inclusion into trio?

I dunno, maybe! I know it's something that shows up in various concurrency libraries, but I've never run into a case where I needed it myself, so I'm pretty fuzzy on what makes it useful. Which is annoying, because it makes it hard to know whether we've got the API right.

How will it help your TeeingReceiveStream?

[ntninja]

After lots of debugging and testing, I wound up not needing the barrier after all. The synchronization provided by trio.open_memory_channel and the manually managed nursery (read: without async with) ended up being good enough – there were just two tricky edge cases with regards to nursery shutdown that I handled slightly wrong. (Not that something like that would surprise you. 😉)

You can view my barrier implementation here: https://pastebin.com/ay3uucfS
Knowing what I know now, I'd rewrite it from scratch using trio.hazmat.ParkingLot – the blueprint I used for this was written with preemptive multitasking in mind which makes everything much more complicated.

[Zac-HD]

Closing this for now, as I don't think we should add new primitives without someone making a strong case for them 🙂