On Mon, Apr 3, 2023 at 5:22 PM Nigel Tao <nigel...@golang.org> wrote:
>
> On Tue, Apr 4, 2023 at 7:56 AM Skip Tavakkolian
> <skip.tavakkol...@gmail.com> wrote:
> > mux9p, Fazlul Shahriar's port of Russ' 9pserve (plan9port)
> > https://github.com/fhs/mux9p/search?q=clientIO
> >
> > ...
> >
> > select {
> > case v, ok := <- counts:
> > // collect samples
> > case reporting <- Stats{ stats }:
> > case <-timer:
> > // calculate stats from samples
> > case cmd, ok := <-commands:
> > // reset counters, restart worker, exit, etc.
> > }
>
> I'd have to study mux9p for longer, but its select chooses between two
> receives, so it could possibly collapse to a single heterogenous
> channel. Indeed, both its channels are already heterogenous in some
> sense. Both its processTx and processRx methods say "switch
> m.tx.Type".
One side serializes the Fcall to 9P packet and the other decodes the
packet into Fcall (there is a check m.tx.Type+1 == m.rx.Type; by 9P
convention).
>
> Your second suggestion, mixing both sends (on the reporting channel)
> and receives, is interesting. Would it be possible to move the
> `reporting <- Stats{ stats }` case inside the `case <-timer: //
> calculate stats from samples` body, though?
Yes, but you'd have to have another select if you don't want to block
on reporting. I have an old piece of code that does that:
https://github.com/9nut/tcpmeter/search?q=Dispatch
I don't know if you're looking for ideas on potential API's for C
implementation, but Plan 9's (and P9P) C API for chan/select is easy
to understand and use (https://9p.io/magic/man2html/2/thread).
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAJSxfm%2BheUJBAWd3fub-9JD2%3DovPR_oqfxWT0Dpnpg8aq5jvFw%40mail.gmail.com.
