On Wed, Aug 13, 2008 at 9:02 AM, Gil Barmwater <[EMAIL PROTECTED]> wrote:
> Just some thoughts on this thread which I have been following with some
> interest. The first is a question: when did the the RexxQueue class
> appear or has it always been there and I just didn't notice it? It
> appears to be an OO way - objects and methods - of dealing with the
> external data queue as opposed to the classic way - keywords (pull,
> push, queue) and functions (queued(), rxqueue()). Do I have that right?
It was always there, but buried internally and it is used behind the
covers to implement pull, push, queue, etc. An instance of RexxQueue
is created when the first interpreter starts up, and all of those
instructions access that RexxQueue singleton. This class was enhanced
and exposed for general use in 3.2.0 after Morten Mork requested the
ability for access to multiple queues at one time (that is, not having
to continually call rxqueue('SET')). Exposing the RexxQueue class was
a very clean solution to this, and gave direct access to queue
objects. However, there are also methods implemented on this class
that have nothing to do with accessing queue instance data, but really
just provide access to the queueing APIs used by the RXQueue
operations.
>
> Secondly, I have mixed feelings about MakeArray removing the lines. I
> believe all the MakeArray methods for other classes leave the source
> object unmodified so this would be an exception. On the other hand,
> being able to do a DO ... OVER and having the queue empty when it
> completes is certainly attractive. Anyone else have any thoughts on this?
I don't have a problem with this. The meaning of Makearray is
dependent on the implementing class, and we already have instances of
makearray methods that can change the internal state of the providing
object. The stream class is the prime example. At a minimum, using a
stream object on DO OVER will move advance the read pointers to the
EOF position. And if the stream in question is a transient stream,
the data returned by makearray has been removed from the stream in the
same fashion it has with queue. Keeping the data in the RexxQueue, in
my opinion, would largely negate the utility being able to iterate
over the queue data using DO OVER. And if you are dealing with a
queue instance that's being used by multiple threads or processes, it
would be difficult at best to delete just the lines that were
processed in the loop
Rick
>
> Rick McGuire wrote:
>> My intent for the makearray method was for it to remove the lines from
>> queue, not leave them in. The intent here is to be able to use a DO
>> OVER loop to iterate over the lines in the queue. So remove the line
>> that put it back. I'd also recommend making just a single call to
>> queued with a temporary variable. Since that has to make an
>> interprocess call to the queue server, that can be sort of an
>> expensive operation.
>>
>> The guarded is not sufficient to protect the queue, which can be
>> accessed not just from another thread, but also from another PROCESS.
>> Guarded is the default behavior, so adding that doesn't really do
>> anything. I'm not too worried about another thread/process writing
>> information to the queue. For that situation, just query the number
>> of lines and return that many lines as a snapshot. It is possible
>> that another thread or process might remove lines while the loop is
>> executing. If the loop doesn't end up finding a line in the queue
>> when pull() is called, .nil we be returned. You can use that to just
>> terminate reading and return whatever you have.
>>
>> In practice, this is not likely to to be any more of a problem than
>> the equivalent loop that people normally use for reading command
>> output that has been captured with the RXQUEUE pipe filter.
>>
>> Rick
>>
>> On Wed, Aug 13, 2008 at 2:01 AM, Sahananda (Jon) Wolfers
>> <[EMAIL PROTECTED]> wrote:
>>
>>>The approach I am thinking of taking for the makearray is this:
>>>
>>>/* -------------------------------------------------------------------------
>>>*/
>>>::method makearray guarded
>>>/* -------------------------------------------------------------------------
>>>*/
>>>arr = .array~new(self~queued)
>>>do i = 1 to self~queued
>>> line = self~pull
>>> arr[i]=line
>>> self~queue(line)
>>>end /* DO */
>>>return arr
>>>
>>>which in itself seems reasonable enough and leaves the RexxQueue in the
>>>state it started in, but what I am wondering is whether the guarded is
>>>sufficient to prevent the rxqueue device writing to the queue through the
>>>API from a concurrent thread whilst it is being cycled through?
>>>
>>>I'm not sure how I would test for this.
>>>
>>>thanks
>>>
>>>Jon
>>>
>>>-------------------------------------------------------------------------
>>>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>>Build the coolest Linux based applications with Moblin SDK & win great
>>>prizes
>>>Grand prize is a trip for two to an Open Source event anywhere in the world
>>>http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>_______________________________________________
>>>Oorexx-devel mailing list
>>>Oorexx-devel@lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
> --
> Gil Barmwater
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
