Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1484

Re: OS_GBPB 12 in a Wimp task

Show all headers | View raw

In message <dea93483-8f06-4b66-8cd0-91b1968f3694@em9g2000vbb.googlegroups.com>
 on 10 Mar 2012 Christopher Bazley  wrote:

> On Mar 8, 10:33 pm, Matthew Phillips <spam20...@yahoo.co.uk> wrote:
>
> > The values in R4 are opaque to the caller, and you are not allowed to
> > manipulate them (e.g. you cannot safely "reverse" to an R4 value you were
> > given earlier in the iteration).  The way they are implemented can be
> > dependent on the underlying filing system or image filing system.  Most
> > will just use the R4 value as an offset of some kind.  Some will probably
> > do things which are rather more cunning.
> >
> > > If you think about it the Filer copy/count must hold the number over
> > > calls.
> >
> > I don't see why it has to, but an inspection of the source code might be
> > quite illuminating!
> 
> From what I've seen of FilerAction's source code, its
> Read_Next_Cache_Full step reads no more than 20 entries at a time from
> the current directory and relies on the offset_to_next_item value
> output by OS_GBPB being valid when it comes to read the next set of
> entries. I assume the Wimp may be polled between calls to
> step_to_next_node().
> 
> The deleted_next_node() function manipulates the offset_to_next_item
> directly by subtracting 1 from it! This implies that the values
> returned by OS_GBPB in R4 must increase monotonically, otherwise
> subtraction would make no sense.
> 
> https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/FilerAct/c/listfiles?rev=4.9

"Monotonically" means that the order is preserved.  For subtraction to make
sense the values in R4 would have to increase in steps of one, which is an
even more severe condition.  I don't know a fancy word for that, but
monotonically isn't it.  (The point about the RISC OS monotonic timer is that
it will never go backwards.  Yes, we'd like it to increase steadily as well,
but that's not so essential!)

My problem with what you're raising is that nowhere in PRM 2 (as far as I can
see) does it say what an "offset" to the next directory entry is.

It tells you three things:

1. Set R4 to 0 for the first call
2. Use the value returned in R4 for the next call
3. If the returned R4 value is -1, there are no more entries

It does not say you can perform subtraction.  You can sort of guess that R4
values will change with each call that returns entries (the call may return
none, for any reason the underlying filing system likes).  But it doesn't
even imply that the R4 values will increase.  It does not say you can even
remember previous R4 values you have been given to jump back to an earlier
point and re-read.

Now I *know* that some filing systems have been written which do not just
return R4 = 1, 2, 3, 4, 5, 6, ..., -1 if you read a single file at a time,
because CPMFS (see http://sinenomine.co.uk/software/ ) implements R4 as an
actual offset into the directory data, which means that it goes up in steps
of at least 32.  Sometimes there will be multiples of 32 for a single step
because to store larger files CP/M uses multiple directory entries.

Whether I ever tested CPMFS against Filer_Action and performed operations
involving lots of files, I have no idea now: I wrote it all about ten years
ago and have not got round to making it 32-bit.  But I don't remember any
problems with it, to the extent I was using it.  And CP/M does not support
subdirectories, which simplifies some aspects of the situation.  If an R4
value which was not aligned to a directory entry (i.e. 32-byte aligned) had
been passed in, no doubt things would have turned unpleasant.  (No doubt I
should have written the code to be more resilient, but I was 25% younger and
n% less wise where n>0.)

Does FileSwitch perform some sort of translation of the R4 values obtained
from the image filing system?  I don't see how it could.

If RISC OS relies on the R4 offset increasing in single steps then

a) Acorn should have spelt that out explicitly in PRM-2, especially in the
sections geared to filing system authors

b) complying would cause extra complications for certain filing systems,
especially if R4 = 5 should mean that we want to read the sixth active
directory entry.  What if there are several deleted entries before the 6th,
and one gets reactivated between calls?  The filing system would have to
maintain an internal mapping for R4 values it had dished out, but would be
hampered by having no idea whether any caller to OS_GBPB 9-12 has finished!

The StrongHelp manuals say "do not assume anything about the value in R4". 
That seems to me to be sound advice.

If FilerAction really does assume the R4 will step up one by one through the
positive integers then I'm worried!

-- 
Matthew Phillips
Durham

Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

OS_GBPB 12 in a Wimp task Christopher Bazley <cs99cjb@gmail.com> - 2012-03-06 14:33 -0800
  Re: OS_GBPB 12 in a Wimp task jeff <jeffrey.a.doggett@gmail.com> - 2012-03-07 00:02 -0800
    Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-08 22:33 +0000
      Re: OS_GBPB 12 in a Wimp task Christopher Bazley <cs99cjb@gmail.com> - 2012-03-10 10:22 -0800
        Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-10 21:04 +0000
          Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-10 23:11 +0100
            Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-11 09:10 +0000
              Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-11 10:41 +0000
              Re: OS_GBPB 12 in a Wimp task Steve Fryatt <news@stevefryatt.org.uk> - 2012-03-11 11:06 +0000
              Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-11 17:56 +0100
                Re: OS_GBPB 12 in a Wimp task Gavin Wraith <gavin@wra1th.plus.com> - 2012-03-11 18:25 +0000
                Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-12 00:33 +0100
                Re: OS_GBPB 12 in a Wimp task Gavin Wraith <gavin@wra1th.plus.com> - 2012-03-12 11:56 +0000
                Re: OS_GBPB 12 in a Wimp task Martin Wuerthner <spamtrap@mw-software.com> - 2012-03-12 16:44 +0100
                Re: OS_GBPB 12 in a Wimp task druck <news@druck.org.uk> - 2012-03-12 20:57 +0000
                Re: OS_GBPB 12 in a Wimp task Martin Wuerthner <spamtrap@mw-software.com> - 2012-03-12 22:26 +0100
                Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-13 17:50 +0100
                Re: OS_GBPB 12 in a Wimp task jgharston <jgh@arcade.demon.co.uk> - 2012-03-13 10:15 -0700
                Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-13 07:34 +0000
                Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-14 06:00 +0100
                Re: OS_GBPB 12 in a Wimp task Christopher Bazley <cs99cjb@gmail.com> - 2012-03-15 02:40 -0700
                Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-15 14:55 +0100
                Re: OS_GBPB 12 in a Wimp task "Ste (news)" <steve@revi11.plus.com> - 2012-03-15 14:46 +0000
                Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-15 18:44 +0100
                Re: OS_GBPB 12 in a Wimp task Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-03-15 19:44 +0000
                Re: OS_GBPB 12 in a Wimp task Alan Adams <alan@adamshome.org.uk> - 2012-03-15 20:36 +0000
                Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-15 20:26 +0000
                Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-16 06:12 +0100
                Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-15 20:34 +0000
                Re: OS_GBPB 12 in a Wimp task Alan Adams <alan@adamshome.org.uk> - 2012-03-15 21:04 +0000
                Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-16 00:17 +0000
        Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-10 23:58 +0000
          Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-11 10:43 +0000
          Re: OS_GBPB 12 in a Wimp task jeff <jeffrey.a.doggett@gmail.com> - 2012-03-12 03:03 -0700
            Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-12 10:44 +0000
            Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-13 07:44 +0000
              Re: OS_GBPB 12 in a Wimp task jeff <jeffrey.a.doggett@gmail.com> - 2012-03-13 03:06 -0700
  Re: OS_GBPB 12 in a Wimp task druck <news@druck.org.uk> - 2012-03-07 10:08 +0000

csiph-web