forums.ps2dev.org

[tjd]

I suspect we have a race condition in the usage of the static rpc buffers. Imagine two threads, both calling send. The first gets all the way through the code into sif, sends the request and blocks on the semaphore waiting for the rpc reply. Because its blocks, the second charges through a similar code path, scribbles all over the outgoing rpc buffer (which often is used as the reply buffer) and then blocks on its own semaphore.

Two threads using the same static buffers at [about] the same time. No?

(In an older code base, I had assigned a per-thread rpc buffer. This prevented the overwrite, but was overkill since the rpc client and servers are essentially not "thread-hot". Which brings up the whole issue of multiple threads doing TCP/IP traffice from the EE. Imagine one doing an accept/recv/select. A simple lock won't work allow multi-threading to occur nicely-- perhaps a better approach is to provide the ability for the IOP server to provide a separate thread per caling thread from the EE)

[mrbrown]

SIF RPC is not reentrant. You cannot have two calls active to the same RPC server at the same time - you're asking for trouble if you try. The EE's RPC client should provide the lock around RPC calls. The IOP shouldn't have to do anything special unless it is sharing buffers between RPC and IOP-land code.

A simple semaphore around RPC client function entry and exit should do it.
_________________
"He was warned..."

[tjd]

Understood, I think you missed the point of having multiple IOP threads-- in effect multiple servers, one for each EE thread.

A "simple lock" will defeat the usefulness of blocking recv*, accept and select calls thus forcing the application to do all the work to simulate multi-threading and cover up for the deffiencies of the underlying mechanism (in this case the rpc model used).