Nate Lawson wrote: > > It's not so much that I volunteered as I said that I'd help with > > thread/proc issues.. > > The trouble was that there are places where it used a proc in the old > > code, but in some cases it needs to be a proc, and in other cases it now > > needs to be a thread. But all they stored was the proc. Also, from > > my memories of the code you needed to understand the protocol to know > > which needed to be which, and I don't know that protocol. > > > > In addition whoever does it needs to remember that any structure that > > stores a thread poitner is probably in error, as threads > > are transient items and any stored thread pointer is probably a wild > > pointer within a few milliseconds of being stored. :-) > > I'll take a whack at it and send it out by tomorrow, working or not.
Don't bother. 8-). The attached patch makes it compile, and takes a shot at doing the right thing. The threasd stuff is problematic; it's useful only for a blocking context. The process stuff is there to identify the connection, actually, which can mean huge latencies (hence the caching of procp). It helps to know that the protocol is exclusively request/response per session, the current code handles only a single session per process (not one per thread), and that lock requests are answered bith synchronously and asynchronously (request/response, then async message on timeout or success). -- Terry
smbfs_thr.diff.gz
Description: GNU Zip compressed data
