> On Aug 19, 2019, at 12:29 PM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>>
>> On top of my proposed interface it would be easy to have a thread that waits for process termination and puts the process object into a go-channel, which the rest of the application can read as desired.
>
> If I've understood correctly, Gambit's whole runtime is based around unified polling like this (lots of different kinds of objects are represented by a variety of ports). However, I can't find the central poll procedures themselves in the manual or wiki.

They aren’t accessible directly.  It has to be that way to centralize the waiting and be able to put the CPU to sleep when nothing is ready for an I/O operation.  It you have several places where select can be called, you can’t say for sure when you can put the CPU to sleep because the other select may be waiting on a different set of fds for which one or more are ready for an I/O.

I guess one way around this would be to expose a “fake”-select that actually funnels the set of fds to the real select, so that there is really just one select at a time.

>
> Just noticed that each Gambit thread has its own mailbox (queue) so most of the building blocks for go-like channels could be in place. IIRC Go channels are higher-order (you can send a channel over another channel); does any Scheme have something like this?

Yes in Gambit and Termite Scheme.  The idea comes from Erlang.  In Erlang processes (“pids”) and channels are fused into one thing, and you can send pids to other processes.  In Gambit you can do this too:

(define server
  (make-thread
   (lambda ()
     (let loop ((i 1))
       (let ((t (thread-receive)))
         (thread-send t i)
         (loop (* i 2)))))))

(define t1
  (make-thread
   (lambda ()
     (let loop ((n 10))
       (if (> n 0)
           (begin
             (thread-send server t1) ;; send the thread id to the server
             (pp (thread-receive))
             (loop (- n 1))))))))

(thread-start! server)
(thread-start! t1)

(thread-join! t1)

;;prints:
1
2
4
8
16
32
64
128
256
512

Termite Scheme is built on top of these features, but with a more concise syntax (for example the procedure “!” is used for thread-send and “?” for thread-receive).  Termite Scheme also serializes thread ids when sending them to another node, and on that node a proxy thread is created that will send whatever it receives in its mailbox to the mailbox of the thread on the source node).  So basically the same model as Erlang is supported.

Marc