Interesting - that page has “ Thread stacks are allocated in shared memory, making it valid to pass pointers to stack variables between threads and procs.”
That seems very difficult to pull off safely. > On Apr 3, 2023, at 9:46 PM, Skip Tavakkolian <skip.tavakkol...@gmail.com> > wrote: > > 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. -- 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/267AC316-F894-4DCB-90E1-465E9B53AC69%40ix.netcom.com.
