Nevin Pratt wrote:
>>> You can only call execute: in one
>> thread, an await its completion, before issuing another call.
>> Yes, precisely. And, that's what using the semaphore accomplishes for
> me-- makes sure only one thread can be in the execute: method at a time.
The design philosophy was to implement the protocol to
communicate with the backend - nothing more, nothing less.
Concurrency issues belong elsewhere, where other tradeoffs
may be applicable. Actually, the idea was that there'd be
a connection pool built on top, to hand out connections.
The pool would only guarantee that it would not give out
the connection again, until it was returned. If the recipient
of the connection chose to share it, then it wouldn't be the
pool's responsibility.
BTW, the state machine design was meant to deal with the
non-deterministic order of packets received from the backend,
not to deal with concurrent usage by the client.