5 ms·

Related: Go-style concurrency for C, http://libmill.org/ http://libmill.org/

alexhutcheson 7y ago
Although note that all libmill coroutines are mapped N:1 to OS threads, while goroutines are mapped M:N to OS threads. In other words, libmill won’t let you have run 2+ coroutines simultaneously on different OS cores, but Go will allow that.
- deleted 7y ago
  [deleted]
- danappelxx 7y ago
  In fact, this means that writing concurrent code is easier as you don’t have to worry about synchronizing access to shared state. It also means scaling applications is straightforward, since you are forced to design for horizontal scalability from the get go (similar to deploying node.js). Ive always found it strange that Go has both channels and locks as synchronization primitives.
  - signa11 7y ago
    unless you start doing blocking read/write...
    - danappelxx 7y ago
      Libdill IO is nonblocking and calls returns a channel. Reading from the channel yields the coroutine, similar to the await statement in some languages.
      - signa11 7y ago
        oh cool ! does that happen for read/write to non-socket fd’s as well ?
        danappelxx 7y ago
        Yeah, see the file descriptors section on this page http://libdill.org/documentation.html http://libdill.org/documentation.html
        signa11 7y ago
        i did before posting here, and could not find anything that might have indicated that i.e. non-socket-fd reads end up with coroutine like semantics...
  - deleted 7y ago
    [deleted]
  - oconnor663 7y ago
    Scaling out is natural when you have a large number of tasks, but it's not always an option when you have one big task. Maybe you need to sort a giant collection, or hash a giant input, or multiply a couple giant matrices. Threads with shared memory can get to work on those problems easily, but separate processes can't, at least not without trying to reorganize the problem to avoid doing tons of IO.
chadcmulligan 7y ago
is there an iOS port you'd know of - couldn't find one

Although note that all libmill coroutines are mapped N:1 to OS threads, while goroutines are mapped M:N to OS threads. In other words, libmill won’t let you have run 2+ coroutines simultaneously on different OS cores, but Go will allow that.

deleted 7y ago
[deleted]
danappelxx 7y ago
In fact, this means that writing concurrent code is easier as you don’t have to worry about synchronizing access to shared state. It also means scaling applications is straightforward, since you are forced to design for horizontal scalability from the get go (similar to deploying node.js). Ive always found it strange that Go has both channels and locks as synchronization primitives.
- signa11 7y ago
  unless you start doing blocking read/write...
  - danappelxx 7y ago
    Libdill IO is nonblocking and calls returns a channel. Reading from the channel yields the coroutine, similar to the await statement in some languages.
    - signa11 7y ago
      oh cool ! does that happen for read/write to non-socket fd’s as well ?
      - danappelxx 7y ago
        Yeah, see the file descriptors section on this page http://libdill.org/documentation.html http://libdill.org/documentation.html
        signa11 7y ago
        i did before posting here, and could not find anything that might have indicated that i.e. non-socket-fd reads end up with coroutine like semantics...
- deleted 7y ago
  [deleted]
- oconnor663 7y ago
  Scaling out is natural when you have a large number of tasks, but it's not always an option when you have one big task. Maybe you need to sort a giant collection, or hash a giant input, or multiply a couple giant matrices. Threads with shared memory can get to work on those problems easily, but separate processes can't, at least not without trying to reorganize the problem to avoid doing tons of IO.

chadcmulligan 7y ago

is there an iOS port you'd know of - couldn't find one