fork of 9front i guess
f763dc1640
there was a race between the sendproc putting the request on the sreqrd[] id and the recvproc handling the response, and potentially freeing the request before the sendproc() was finished with the request (or the fid). so we defer allocating a request id and putting it on the sreqrd[] stage after we have completely generated the request in vpack(). this prevents the handling of the request before it is even sent. this also means that the SReq should not be touched after calling sendpkt(), submitreq(), submitsreq(). secondly, putsfid() needs to acquire the RWLock to make sure sendproc() is finished with the request. the scenario is that recvproc() can call respond() on the request before sendproc() has unlocked the SFid. |
||
|---|---|---|
| 386 | ||
| 68000 | ||
| 68020 | ||
| acme | ||
| adm/timezone | ||
| amd64 | ||
| arm | ||
| arm64 | ||
| lib | ||
| mips | ||
| power | ||
| power64 | ||
| rc | ||
| sparc | ||
| sparc64 | ||
| spim | ||
| sys | ||
| .hgignore | ||