/me reads Ross's post more carefully.... Ah, so it sounds like you are indeed doing something like "spawn a goroutine for each request" and the way that you keep things in the proper order is by requiring method implementations to call the server.Ack function. How does user-defined object state fit in to this model? I guess it's probably accessible through some mutex-protected reference that's part of the `call` parameter?
On Sat, Jul 22, 2017 at 11:01 PM, David Renshaw <[email protected]> wrote: > On Sat, Jul 22, 2017 at 10:49 PM, David Renshaw <[email protected]> > wrote: > >> Would it work for the go-capnproto2 RPC system to spawn a new goroutine >> for each method invocation? Then the user-supplied method implementation >> code would always get executed on a separate goroutine from the object's >> main loop, avoiding the deadlock. (There would be no "start the work" >> phase.) Admittedly, one downside to this approach is that method >> implementations would no longer get direct access to user-defined object >> state (also known as "this" or "self"). However, method implementations >> could probably still get a mutex-protected reference to the object state, >> and maybe that's good enough. >> >> > I suppose that another problem with this is that Go's scheduler might > scramble the order of method calls between the time when they are > dispatched to separate goroutines and the time when they are actually > executed. > > > > > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
