Application-specific context in ArgusParserStruct

[Carter Bullard]

Hey Harry,
Sorry I didn't see your email until now.  Yes, we have a global lock  
for the global parser, and
its used for synchronization.  We "Clone" parsers when we need  
multiple parsers, and keep
a list of them so the system can keep track.  When we clone them, all  
the parameters are
copied.   Each parser then ends up with its own locks, memory whatever  
it needs.

Argus clients don't worry about the local vs global parser, as its  
design to only use one
parser at a time.  But generally where they use the ArgusParser  
global, it should be related
to some action that is system oriented (like memory management, some  
queue use), rather
than context oriented.  That is the design, but not sure if all are  
playing by the rules.

Carter

On Jun 5, 2009, at 10:44 AM, Harry Bock wrote:

> Hey Carter,
>
> Thanks for adding that field, that will be immensely helpful.  I  
> know taking over a random field is a (very) bad idea, but I need it  
> for the time being, until I rebase against the latest version of  
> argus-clients.
>
> In terms of multiple Argus parsers, I was actually going to ask a  
> question about that.  The global instance ArgusParser is used in  
> quite a bit of code, including routines that take an  
> ArgusParserStruct argument; how does this play into thread safety of  
> the library? As you've written clients before with multiple  
> ArgusParsers, is there anything I need to do to ensure there won't  
> be any race conditions?
>
> Thanks,
> Harry
>
> On Fri, Jun 5, 2009 at 10:17 AM, Carter Bullard <carter at qosient.com>  
> wrote:
> Hey Harry,
> I wouldn't "take over" any field that is in the ArgusParserStruct.   
> Argus is a subset
> of a larger system.  At anytime, I may bring over code that uses  
> these variables,
> and then you would really not be in a good position at all.
>
> Adding a variable is a no brainer, but the name needs a little work.
> I've added "void *ArgusClientContext" to the ArgusParserStruct, and  
> it will
> be in the next upload.
>
> A few concepts that you need to consider.  Don't assume that there  
> is only
> one ArgusParser.  The design is that within the context of the  
> callout routines,
> there is only one valid ArgusParser, and its the one that we are  
> passing.
> For argus-clients, there is only one, but for other systems, there  
> are multiple
> ArgusParser's, so just take that into consideration, if you can.
>
> Be sure and deallocate the ArgusClientContext in your  
> RaParseComplete()
> routine.
>
> Carter
>
>
>
>
>
> On Jun 3, 2009, at 10:29 PM, Harry Bock wrote:
>
>> Hi Carter,
>>
>> I've come across a little snag in developing Periscope; I'd like to  
>> store a pointer to a mutable context relevant only to my  
>> application, without adding more fields to ArgusParserStruct and  
>> without using global variables.  I've noticed that a lot of the  
>> client-specific data structures are all stored within  
>> ArgusParserStruct, but there is no "agnostic" field where I could  
>> simply link in my own.
>>
>> I've worked around this by saving my context in parser- 
>> >RaFlowModel, which I've verified does not get modified by any  
>> Argus client function that I'm using, directly or indirectly.  In  
>> the future, however, I'd suggest adding a simple field like so to  
>> ArgusParserStruct:
>>
>> struct ArgusParserStruct {
>>   int status, ...;
>>   ...
>> +  void *context;
>> };
>>
>> As Argus clients are currently linked statically to the common/ 
>> event/parser libraries, binary compatibility shouldn't be an issue,  
>> but you obviously know the direction of Argus far better than I  
>> could, so I don't want to change anything sensitive.  If the change  
>> is acceptable, could it be included in the final release of argus- 
>> clients-3.0.1?
>>
>> This change would also greatly help reduce clutter in  
>> ArgusParserStruct, as you could move client-specific data (such as  
>> what is needed by radium, rabins, rahisto, etc) out of common code  
>> and straight into the application.  I'd be more than happy to  
>> contribute the patches necessary to all of the Argus clients, given  
>> a week or two.
>>
>> -- 
>> Harry Bock
>> Software Developer, Package Maintainer
>> OSHEAN, Inc.
>> Email: harry at oshean.org
>> PGP Key ID: 546CC353
>
>
>
>
>
>
> -- 
> Harry Bock
> Software Developer, Package Maintainer
> OSHEAN, Inc.
> Email: harry at oshean.org
> PGP Key ID: 546CC353

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090626/ac015073/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090626/ac015073/attachment.bin>