On 9/9/05, Dave Shield <[EMAIL PROTECTED]
> wrote:
Great, thanks. At least this will help people like me from thinking its threadsafe when its not.
Yeah, I noticed its rather out of date, but I was able to figure everything out from it and everything but v3 seemed to work as described.
I make take this on in a few weeks if theres no one else. As I mentioned we are using the library for commercial purposes and for now we are having to just drop v3 support. Very few people seem to actually use v3 anyway so its not super critical, but I'd like to see it working correctly with threads. I'm sure there are others who would like to use it as well but can't.
Yeah, using semaphores/mutex's to lock access to the list is an option, but the intial thread safety design using the single session API seemed to intentionally avoid that. I suspect thats because sempahores/mutex's aren't well standardized across platforms (Win32...) and performance is better without them. The other difficulty is that the list address is retrieved but then unused for sometime and passsed around with pointers with different names so its a bit of work figuring out where the list is getting modified and getting the locks in all the right spots. It could be done though.
On Thu, 2005-09-08 at 09:15 -0700, John McCaskey wrote:
> I was under the impression from reading
> http://www.net-snmp.org/docs/README.thread.html that as long as I
> stuck to the Single Session API for forming and sending requests I
> would be ok. However, it appears that while this is true for v1 and
> v2c requests it does not apply to v3.
> Is this a known issue? If I don't get feedback telling me I'm crazy
> or this is known
No - you're not crazy.
Yes, it is known (though not very widely).
> At the very least someone should update the README.thread to warn
> of this issue.
That README was updated earlier this year to mention the SNMPv3
problem. Unfortunately, that was only done on the main development
branch, so wasn't included in the latest releases. I've just copied
this text to the other branches too.
Great, thanks. At least this will help people like me from thinking its threadsafe when its not.
But fundamentally, this README is pretty much untouched from the
original version that Mike supplied way back in 1999. It wouldn't
surprise me if it's somewhat out of date by now, and would probably
benefit from a wholescale review and revision.
Yeah, I noticed its rather out of date, but I was able to figure everything out from it and everything but v3 seemed to work as described.
> Is there work towards making v3 thread safe when using the single
> session API?
Ummm... I doubt it.
We need somewhere ready and willing (and able) to tackle this.
(Such is the down-side of Open Source development!)
I make take this on in a few weeks if theres no one else. As I mentioned we are using the library for commercial purposes and for now we are having to just drop v3 support. Very few people seem to actually use v3 anyway so its not super critical, but I'd like to see it working correctly with threads. I'm sure there are others who would like to use it as well but can't.
> My first ignorant thought it just put the userList in the session
> object... but maybe its not that simple.
Probably not.
The userList is a collection of *all* the users known to the application
(or learned during the course of operation). It probably wouldn't be
sensible to have multiple copies of this list.
I'm no thread expert, but I suspect that it's more a case of tracking
all the places where this list is updated, and protecting those with a
suitable semaphore lock, or something similar.
Yeah, using semaphores/mutex's to lock access to the list is an option, but the intial thread safety design using the single session API seemed to intentionally avoid that. I suspect thats because sempahores/mutex's aren't well standardized across platforms (Win32...) and performance is better without them. The other difficulty is that the list address is retrieved but then unused for sometime and passsed around with pointers with different names so its a bit of work figuring out where the list is getting modified and getting the locks in all the right spots. It could be done though.
But this isn't really my area (and I haven't looked at the code), so
take that with a large dose of salt!
Dave
