[HN Gopher] Libdill: Structured Concurrency for C (2016)
___________________________________________________________________
Libdill: Structured Concurrency for C (2016)
Author : ibraheemdev
Score : 44 points
Date : 2021-06-01 16:39 UTC (6 hours ago)
(HTM) web link (libdill.org)
(TXT) w3m dump (libdill.org)
| [deleted]
| majke wrote:
| I've always been Mr Sustrik's fan, but this has a special place
| in my heart.
|
| I highly recommend reading the "What is structured concurrency?"
| section with understanding. I think this is a big deal.
|
| Why?
|
| Let's start from another angle. Have you ever seen
| `pthread_cancel` manpage? Or "POSIX.1 Cancellation points"? This
| is an utter mess!
|
| More than that, _any_ framework I've seen that allows to "kill" a
| coroutine (goroutine, thread, actor) in the end reproduces this
| "pthread_cancel" drama.
|
| Basically, thread cancellation seems to be an unsolved computer
| science problem.
|
| Mr Sustrik in "structured concurrency" makes one easy assumption,
| which in practice is sensible. It's not academic proposal. It's
| totally useable. The programmer must understand it and use it
| properly, but this is a totally workable constraint - that is: -
| the thread must exit before its parent dies.
|
| This small thing seems to be making all the differnce.
|
| Anyhow. If you ever wondered why killing threads is a mess,
| libdill proposes a solution.
| ibraheemdev wrote:
| > I highly recommend reading the "What is structured
| concurrency?" section with understanding. I think this is a big
| deal.
|
| The idea was originally introduced and explained in more depth
| here: https://250bpm.com/blog:71/
| failwhaleshark wrote:
| I saw this in 2017. Unfortunately, not much activity now.
| https://github.com/sustrik/libdill/commits/master
|
| Might be fun to play with, but I wouldn't rely on it. Generally,
| better off with libuv for existing projects or Rust for greener
| fields where lifetimes are checked and safe concurrency is much
| easier.
| 37ef_ced3 wrote:
| Or Go, the concurrency utopia
| ibraheemdev wrote:
| I wonder if this idea could be implemented in Rust with
| destructors.
| staticassertion wrote:
| Drop is synchronous, and it's unclear what async Drop would
| look like afaik, so not today.
| ibraheemdev wrote:
| The drop implementation could push to a worker queue running
| in the background.
| staticassertion wrote:
| If you don't wait for a response you're not really getting
| the same benefit.
| Matthias247 wrote:
| You can do it for Rust threads - but it gets tricky with Rust
| coroutines (async functions).
|
| I made an attempt of implementing it for async Rust in
|
| https://github.com/tokio-rs/tokio/issues/1879
|
| with a concrete implementation in
|
| https://github.com/tokio-rs/tokio/pull/2579
|
| It mostly follows the Kotlin model of structured concurrency.
| However it has its sets of drawbacks due to Rust Futures being
| immediately cancellable, which then leads to problem if a
| parent task gets simply dropped.
|
| In order to handle that case better I've written a proposal for
| async functions that run to completion with https://rust-
| lang.zulipchat.com/#narrow/stream/187312-wg-asy... . However
| that is all theoretical, and might never see the light of the
| day.
| ibraheemdev wrote:
| Have any languages implemented this idea?
| Jtsummers wrote:
| See Ada's tasks for something approaching this concept, though
| it's not strict. That is, it's still possible to have
| "unstructured" concurrency in Ada. But tasks and instances of
| task types have lexical scope like any other variable, by
| default. I started exploring it a while ago but my interest
| kind of petered out so I never put anything together to really
| present on it.
|
| https://learn.adacore.com/courses/intro-to-ada/chapters/task...
|
| You can read about it there, and the code segments can be
| edited so you can play around with different variations.
| bullen wrote:
| I'm just going to leave this here, don't shoot the messenger, I
| already had a bad day of downvoting:
|
| "Many lock-free structures offer atomic-free read paths, notably
| concurrent containers in garbage collected languages, such as
| ConcurrentHashMap in Java. Languages without garbage collection
| have fewer straightforward options, mostly because safe memory
| reclamation is a hard problem..." - Travis Downs
| https://travisdowns.github.io/blog/2020/07/06/concurrency-co...
| pkhuong wrote:
| From the same paragraph: "there are still some
| (http://concurrencykit.org/) good (https://software.intel.com/c
| ontent/www/us/en/develop/documen...) options (https://github.co
| m/facebook/folly/tree/master/folly/concurre...) out there."
|
| There are plenty of practical solutions to the safe memory
| reclamation problem in C. The language just doesn't force one
| on you.
|
| From epoch-based reclamation (https://github.com/concurrencykit
| /ck/blob/master/include/ck_..., especially with the
| multiplexing extension to Fraser's classic scheme), to
| quiescence schemes (https://liburcu.org/), or hazard pointers (
| https://github.com/facebook/folly/blob/master/folly/synchron...
| , or https://pvk.ca/Blog/2020/07/07/flatter-wait-free-hazard-
| poin...)... or even simple using a type-stable (https://www.use
| nix.org/legacy/publications/library/proceedin...) memory
| allocator.
|
| In my experience, it's easier to write code that is resilient
| to hiccups in C than in Java. Solving SMR with GC only offers
| something close to lock-freedom when you can guarantee global
| GC pauses are short enough... and common techniques to bound
| pauses, like explicitly managed object pools, land you back in
| the same problem space as C.
___________________________________________________________________
(page generated 2021-06-01 23:01 UTC)