On Wed, 2005-11-09 at 15:27 -0500, Haizhu Liu wrote:
> I see on the other thread:
>
> "Note that it's this 'snmp_sess_transport' API works with
> the opaque (session_list) pointer - *NOT* the "netsnmp_session"
> pointer returned by 'snmp_open()'.
>
> So you probably want something like:
>
>
I saw statement "Note that the single session API uses the existing callback
mechanisms in the SNMP library. This means a callbakc function can not use
the single API to furthre process the session"
Can a call back function decare a new session, and perform actions on the
n
I see on the other thread:
"Note that it's this 'snmp_sess_transport' API works with
the opaque (session_list) pointer - *NOT* the "netsnmp_session"
pointer returned by 'snmp_open()'.
So you probably want something like:
netsnmp_session *sess = snmp_open(...);
netsnmp_transport *t = s
On 9/13/05, Robert Story <[EMAIL PROTECTED]> wrote:
On Fri, 9 Sep 2005 11:53:38 -0700 John wrote:.There is some support for multi-thread resource locking. See the mt_supportheader and code, and grep for 'snmp_res_' in the code. Don't know the state ofthe code, however. But it should server as a sta
On Fri, 9 Sep 2005 11:53:38 -0700 John wrote:
JM> Yeah, using semaphores/mutex's to lock access to the list is an option,
JM> but the intial thread safety design using the single session API seemed to
JM> intentionally avoid that. I suspect thats because sempahores/mutex
> On Fri, 9 Sep 2005 11:53:38 -0700, John McCaskey <[EMAIL PROTECTED]> said:
John> Yeah, using semaphores/mutex's to lock access to the list is an
John> option, but the intial thread safety design using the single
John> session API seemed to intentionally avoid that.
There a number of places
999. It wouldn't
surprise me if it's somewhat out of date by now, and would probablybenefit 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
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
ml 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. The base of the problem seems
to be that ./snmplib/snmpusm.c defines a global linked list (userList)
