On Sun, Jul 23, 2017 at 12:10 AM, David Renshaw <[email protected]> wrote:
> /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? > > /me reads some more source code... It looks like <https://github.com/capnproto/go-capnproto2/blob/9eb2b19e6905291aa373d2d0bc1516c0abb88b5d/rpc/embargo_test.go#L80> method implementations get direct access to object state. So if a method implementation needs unsynchronized access to the state, that must happen before server.Ack() is called, right? So you can think of server.Ack() as "releasing the lock" on the object. From this perspective, I don't think it's surprising or too burdensome that recursive calls to the object can trigger deadlock if they happen before server.Ack(). -- 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.
