4 ms·

By multithreading, do you mean concurrency, or does Gambit expose raw threads to user programs? I'm rather convinced that a pthreads-like or Java-like interfac

by KMag 11y ago

By multithreading, do you mean concurrency, or does Gambit expose raw threads to user programs? I'm rather convinced that a pthreads-like or Java-like interface to threads is too low-level and error-prone for most programming outside of kernel or standard library programming. We have less error-prone concurrency interfaces in Erlang-like CSP or Scala Actors.

pflanze 11y ago
I was referring to its built-in raw threads including mutexes, condition variables, and what it calls mailboxes (communication channels between threads) as well as object ports. You can build an Erlang style system easily on top of those (this is Scheme, after all, so you've got macros to help build abstractions, although the system doesn't offer the means to enforce separation (your programs can access symbols that allow to circumvent any separation attempts)), as the Termite project(1) in fact did (also about a decade ago). (1) https://duckduckgo.com/html/?q=gambit+termite https://duckduckgo.com/html/?q=gambit+termite I was mentioning threads since Marc Feeley, its author, was a forerunner in implementing threads on Scheme systems (he authored the threading SRFI (2)). It's a green threading system (support for millions of threads, it doesn't come with support for libev though, so YMMV). (2) http://srfi.schemers.org/srfi-18/ http://srfi.schemers.org/srfi-18/ Thing is, the thread system, like the rest of the system (e.g. he devised an I/O layer that tries to be OS agnostic), tries to come as shiny closed system for the user (with comprehensive user docs), whereas I'd much prefer for the parts to be openly accessible/exchangable. For example I'm often barely using the built-in OS-agnostic I/O layer and instead wrote interfaces to POSIX via the FFI. And I don't use the threading system often. My biggest use case for multi-threading is SMP support which I need to do by running separate Gambit instances (or by way of fork), accessing a common storage layer implemented via POSIX (currently in the works, and I'm writing it in a way that should make it easy for me to move to other Scheme systems). In essence, from my point of view it's a system from academia with a quite explicit attempt to be practical for industrial use but falling short on the latter front pretty much exactly because it tries to do the latter itself.

by KMag 11y ago

pflanze 11y ago

I was referring to its built-in raw threads including mutexes, condition variables, and what it calls mailboxes (communication channels between threads) as well as object ports. You can build an Erlang style system easily on top of those (this is Scheme, after all, so you've got macros to help build abstractions, although the system doesn't offer the means to enforce separation (your programs can access symbols that allow to circumvent any separation attempts)), as the Termite project(1) in fact did (also about a decade ago). (1) https://duckduckgo.com/html/?q=gambit+termite https://duckduckgo.com/html/?q=gambit+termite I was mentioning threads since Marc Feeley, its author, was a forerunner in implementing threads on Scheme systems (he authored the threading SRFI (2)). It's a green threading system (support for millions of threads, it doesn't come with support for libev though, so YMMV). (2) http://srfi.schemers.org/srfi-18/ http://srfi.schemers.org/srfi-18/ Thing is, the thread system, like the rest of the system (e.g. he devised an I/O layer that tries to be OS agnostic), tries to come as shiny closed system for the user (with comprehensive user docs), whereas I'd much prefer for the parts to be openly accessible/exchangable. For example I'm often barely using the built-in OS-agnostic I/O layer and instead wrote interfaces to POSIX via the FFI. And I don't use the threading system often. My biggest use case for multi-threading is SMP support which I need to do by running separate Gambit instances (or by way of fork), accessing a common storage layer implemented via POSIX (currently in the works, and I'm writing it in a way that should make it easy for me to move to other Scheme systems). In essence, from my point of view it's a system from academia with a quite explicit attempt to be practical for industrial use but falling short on the latter front pretty much exactly because it tries to do the latter itself.