Thanks! One thing you can do, when the place-specific communication takes multiple steps is to, like you did in the first example, put the channels into a hash, but then on each iteration of the loop, pull all of them out and put them into a giant select that takes the relevant step forward for that specific piece of the communication (you use handle-evt to wrap the successful communication with the state update and then the call to `loop` back for some other step or of (potentially) some other communication).
The advantage to this kind of setup is that you have sequential access to some shared state that is kept entirely on the server side. So you completely avoid the conventional pitfalls of mutable state combined with concurrency. For example, if your main loop was the one that was parcelling out, say, files to compile, you could keep a list of the pending files to compile on the server and when each worker finished with a file or encountered a new file, it would let the server know and the server would tell it what to do, eg "oh, wait, someone else is compiling that file" or "go ahead, I've noted that you're the one that's compiling that file and I'll tell others who also need it to wait for you to finish". And the latter case, the worker that was waiting would also get an evt that would become ready when the file was finish compiling (which would also be mediated through the server). Robby On Fri, Jun 21, 2019 at 11:02 PM Matthew Butterick <m...@mbtype.com> wrote: > > > > On 06 15 19, at 8:31 AM, Robby Findler <ro...@cs.northwestern.edu> wrote: > > A standard way to work with this is to send a channel over in the > first communication and then the communication that's specific to that > initial request happens on that channel. The precise way you set this > up depends on what invariants of the communication you want. Like, you > can create a new thread and just do all the communication there > > > > And here's a threaded version, which I agree is neater, because by closing > over each worker channel, the threads make other channel-tracking > housekeeping unnecessary. > > #lang racket > (require racket/place) > (provide main) > > (define (main) > (define loopback-p > (place lch > (let loop () > (define wp (place-channel-get lch)) > (thread (λ () (let loop () > (place-channel-put wp (place-channel-get wp)) > (loop)))) > (loop)))) > > (define worker-ps > (for/list ([i (in-range (processor-count))]) > (place wch > (let make-request ([count 1]) > (define countout (place-channel-put/get wch count)) > (displayln (format "worker request ~a:~a got response ~a:~a ~a" > 0 count 0 countout > (if (eq? count countout) "" "### fail"))) > (make-request (add1 count)))))) > > (for ([worker-p (in-list worker-ps)]) > (place-channel-put loopback-p worker-p)) > > (map place-wait worker-ps)) > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/A5055051-898C-46F9-82C6-BD0A50AC4D20%40mbtype.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAL3TdOMxQpQWTiCgvirzy9_gAvUxdbSxTdxurMwnuSGHTThQfg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
