See inline comments -
Rick McGuire wrote:
> 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.
>
Ah, so it was "revealed" it 3.2. Now I don't feel so bad :-) And, yes,
I saw that there were other methods besides those corresponding to the
classic keywords.
>
>
>>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
>
Forgot about the stream class, probably because I haven't used its
MakeArray (although there has been some recent discussion about it vs.
ArrayIn which should have reminded me). Since this won't be the first
case where the source object is modified by MakeArray, I'm happy with it
emptying the queue. :-)
>
>>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
>
>
--
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
