en none are in flight.
>>
>> setters can then block waiting for the lock to be freed.
>>
>> That's guaranteed to be compatible with any correct current practice.
>>
>> I just hate to put all that complexity in there.
>>
>> From: Steve Lawrence
>> Sent: Wedn
us out of trouble.
From: Steve Lawrence
Sent: Thursday, March 26, 2020 7:39 AM
To: dev@daffodil.apache.org
Subject: Re: Compiler.setExternalDFDLVariable(s) considered challenged
Even if we did add the locking, it's still possible to use these
incorrectly, right
> From: Steve Lawrence
> Sent: Wednesday, March 25, 2020 3:44 PM
> To: dev@daffodil.apache.org
> Subject: Re: Compiler.setExternalDFDLVariable(s) considered challenged
>
> My one minor concern about the locking after parse/unparse is that it
> changes behavior, an
d.
That's guaranteed to be compatible with any correct current practice.
I just hate to put all that complexity in there.
From: Steve Lawrence
Sent: Wednesday, March 25, 2020 3:44 PM
To: dev@daffodil.apache.org
Subject: Re: Compiler.setExternalDFDLVariable(s) considered
ll work,
> just get deprecation warnings.
>
>
> From: Steve Lawrence
> Sent: Wednesday, March 25, 2020 12:05 PM
> To: dev@daffodil.apache.org
> Subject: Re: Compiler.setExternalDFDLVariable(s) considered challenged
>
> This feels like the
eprecation
warnings.
From: Steve Lawrence
Sent: Wednesday, March 25, 2020 12:05 PM
To: dev@daffodil.apache.org
Subject: Re: Compiler.setExternalDFDLVariable(s) considered challenged
This feels like the right approach. Thoughts on instead of having to
manu
ters and simply more arguments
> to the parse/unparse calls.
>
> ________
> From: Beckerle, Mike
> Sent: Wednesday, March 25, 2020 11:29 AM
> To: dev@daffodil.apache.org
> Subject: Re: Compiler.setExternalDFDLVariable(s) considered challenged
>
>
Agreed on deprecating setting variables in the Compiler. It really just
doesn't make sense to be doing that.
Definitely seems reasonable to add the ability to set variables when
calling parse/unparse as that's the most threadsafe way to handle it,
and feels natural to me. Note that we still have
arguments to
the parse/unparse calls.
From: Beckerle, Mike
Sent: Wednesday, March 25, 2020 11:29 AM
To: dev@daffodil.apache.org
Subject: Re: Compiler.setExternalDFDLVariable(s) considered challenged
To respond to my own thread here, I think given that we allo
To respond to my own thread here, I think given that we allow multiple
simultaneous calls to parse/unparse from different threads, we must say that
the DataProcessor object is immutable once parse or unparse are called.
I suppose we could say that it is mutable, but behavior is undetermined if
10 matches
Mail list logo
