Application-specific context in ArgusParserStruct

[Harry Bock]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090605/ff74ce9f/attachment.html>