OK,
thanks for your help RIck, I'll get on with this over the next few days.
Once again I'm on site, so it may be a while before I get a chance to post.
Jon
2008/8/13 Gil Barmwater <[EMAIL PROTECTED]>
> 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
>
-------------------------------------------------------------------------
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
