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

Groups > comp.sys.acorn.programmer > #1473 > unrolled thread

OS_GBPB 12 in a Wimp task

Back to article view | Back to comp.sys.acorn.programmer

Contents

  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

Page 1 of 2  [1] 2  Next page →

#1473 — OS_GBPB 12 in a Wimp task

Hello,

I am thinking about moving some very generic code that is shared
between several of my programs into a C library. The code in question
uses OS_GBPB 12 recursively to enumerate all of the entries in a
specified directory and its subdirectories (depth-first search of the
directory tree). I shall probably implement an interface that looks
something like this:

typedef struct
{
  void *load_address;
  void *exec_address;
  size_t length;
  unsigned int attributes;
  int object_type;
  int file_type;
}
DirEntry;

const _kernel_oserror *DirIterator_init( DirIterator *dir, const char
*path_name );
void DirIterator_get_entry( DirIterator *dir, DirEntry *entry );
int DirIterator_get_path_name( DirIterator *dir, char *str, size_t
size );
const _kernel_oserror *DirIterator_advance( DirIterator *dir );
void DirIterator_final( DirIterator *dir );

My question is: How long is it safe to retain the continuation value
returned in R4 by SWI OS_GBPB 12? Can I retain it across calls to SWI
Wimp_Poll or Wimp_PollIdle, then feed it back into the same SWI?

Obviously my C library won't know anything about whether the Wimp has
been polled between calls to its DirIterator_advance() function, so
the only safe thing to do would be to cache the entire contents of
every directory as soon as I discover it. Given that my code would
have to guess the initial buffer size and OS_GBPB doesn't guarantee to
return as many directory entries as requested by the caller, that
could take many SWI calls and a lot of memory for every branch of a
deep directory tree.

Any thoughts are welcome.

--
Chris Bazley

[toc] | [next] | [standalone]

#1475

Hi,

> My question is: How long is it safe to retain the continuation value
> returned in R4 by SWI OS_GBPB 12? Can I retain it across calls to SWI
> Wimp_Poll or Wimp_PollIdle, then feed it back into the same SWI?

Many hours!

The only thing that affects anything held in R4 is if another task
alters
the directory between calls.

If you think about it the Filer copy/count must hold the number over
calls.

Jeff

[toc] | [prev] | [next] | [standalone]

#1481

In message <9fa95124-990a-43e2-a561-b4c03bff439c@p7g2000yqk.googlegroups.com>
 on 7 Mar 2012 jeff  wrote:

> > My question is: How long is it safe to retain the continuation value
> > returned in R4 by SWI OS_GBPB 12? Can I retain it across calls to SWI
> > Wimp_Poll or Wimp_PollIdle, then feed it back into the same SWI?
> 
> Many hours!
> 
> The only thing that affects anything held in R4 is if another task alters
> the directory between calls.

Exactly: and that can easily happen across calls to Wimp_Poll.  You might end
up skipping a file, or reading the same one twice, depending on whether files
had been added or removed from the directory.

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!

Matthew

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1482

On Mar 8, 10:33 pm, Matthew Phillips <spam20...@yahoo.co.uk> wrote:
> In message <9fa95124-990a-43e2-a561-b4c03bff4...@p7g2000yqk.googlegroups.com>
>  on 7 Mar 2012 jeff  wrote:
>
> > > My question is: How long is it safe to retain the continuation value
> > > returned in R4 by SWI OS_GBPB 12? Can I retain it across calls to SWI
> > > Wimp_Poll or Wimp_PollIdle, then feed it back into the same SWI?
>
> > Many hours!
>
> > The only thing that affects anything held in R4 is if another task alters
> > the directory between calls.
>
> Exactly: and that can easily happen across calls to Wimp_Poll.  You might end
> up skipping a file, or reading the same one twice, depending on whether files
> had been added or removed from the directory.
>
> 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

Cheers,
--
Chris Bazley

[toc] | [prev] | [next] | [standalone]

#1484

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

[toc] | [prev] | [next] | [standalone]

#1485

On Sat, 10 Mar 2012 21:04:35 GMT, Matthew Phillips 
<spam2011m@yahoo.co.uk> wrote:

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

No, this is FilerAction, not RISC OS!


Just read all the relevant info in PRM2 (PDF, search for "gbpb") and 
five things are clear:
   1. R4 is zero to start.
   2. R4 is -1 when done.
   3. R4 given is value to give on next call.
   4. R4 is an offset, but...
   5. ...absolutely NOWHERE does it say what sort of offset.


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

It's making assumptions. Perhaps based upon knowledge of existent 
Acorn filing systems, but even so it is an assumption.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1487

In message <almarsoft.5374763469681712868@news.orange.fr>
 on 10 Mar 2012 Rick Murray  wrote:

> On Sat, 10 Mar 2012 21:04:35 GMT, Matthew Phillips 
> <spam2011m@yahoo.co.uk> wrote:
> 
> > If RISC OS relies on the R4 offset increasing in single steps then
> 
> No, this is FilerAction, not RISC OS!

I should have said "an important and widely used component of RISC OS".

If FilerAction is really making these assumptions it's bad news.  I'm afraid
I didn't have time last night to get my head round the code Chris Bazley
linked to, so I'm still hoping he may have misunderstood it and that
FilerAction does not make these sorts of assumptions.

Given Chris Johnson's experiences with DrWimp, it sounds like some testing of
FilerAction against Fat32FS could be interesting.  It's in much wider use
than CPMFS, that's for sure!

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1488

In article <8299b36e52.Matthew@sinenomine.freeserve.co.uk>,
   Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> Given Chris Johnson's experiences with DrWimp, it sounds like some
> testing of FilerAction against Fat32FS could be interesting.  It's
> in much wider use than CPMFS, that's for sure!

I use (and maintain) SyncDiscs, which now spawns fileractions for all
the copy or wipe actions when used in multitasking mode. I, and
others, use it routinely on the ARMini to back up to Fat32 formatted
devices, without having run in to problems. That is not to say there
isn't a gotcha laying in wait somewhere.

-- 
Chris Johnson

[toc] | [prev] | [next] | [standalone]

#1490

On 11 Mar, Matthew Phillips wrote in message
    <8299b36e52.Matthew@sinenomine.freeserve.co.uk>:
 
> If FilerAction is really making these assumptions it's bad news.  I'm
> afraid I didn't have time last night to get my head round the code Chris
> Bazley linked to, so I'm still hoping he may have misunderstood it and
> that FilerAction does not make these sorts of assumptions.

I've an idea that this has come up before, in similar circumstances, so
either Chris is just repeating that, or he's correct about how it all works
(or both, of course).

I also haven't had time to read the FilerAction code, but something has just
occurred to me.  A few weeks back, I tried to use FilerAction to delete a
block of files on a Sunfish mount.  It would delete one or two, then fail
with "File Not Found".  Deleting them one at a time worked.  It may be
totally unrelated, but Sunfish seems to be a prime candidate for making
creative use of R4.  At the time I blamed Sunfish, but wasn't able to
investigate further or put a bug report together.

I've just had cause to try it again, and the same failure happened.

> Given Chris Johnson's experiences with DrWimp, it sounds like some testing
> of FilerAction against Fat32FS could be interesting.  It's in much wider
> use than CPMFS, that's for sure!

Have no Beagleboard or ARMini users reported problems, then?

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                             Saturday 28 April 2012
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

[toc] | [prev] | [next] | [standalone]

#1491

On Sun, 11 Mar 2012 09:10:22 GMT, Matthew Phillips 
<spam2011m@yahoo.co.uk> wrote:

> If FilerAction is really making these assumptions it's bad news.

It might be time to either:

1. Tweak FilerAction to remember past results of R4 and not assume 
what future should be (other than as specified in the call)
Or:
2. Amend the documentation to state that this behaviour happens.

The second is option is heinous. The first is really non-optimal but 
at least more logical than subtracting one.

The second option *could* be dealt with by some filing systems - like 
the poster who used R4 as an offset, simply take R4 and multiply by 
32 (well, MOV with LSL) to turn the number into the offset desired.
However, in the case that the API makes no such specification, it 
would seem more logical to look to fixing FilerAction.


The big problem I see is that the file system does not have a 
mechanism to preserve state across polls.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1492

In message <almarsoft.6587021169203963779@news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> The big problem I see is that the file system does not have a 
> mechanism to preserve state across polls.

Surely that should be up to the application that is doing the polling,
or have I misconstrued what you are saying?

The heart of RiscLua's directory iteration has prototype:

extern int rdir(const char *dir, char *buf, int buflen, int offset);

realized by this assembler code:

rdir
 STMFD sp!,{R1-R6,R14}
 MOV R6,#0
 MOV R5,R2
 MOV R4,R3
 MOV R3,#1
 MOV R2,R1
 MOV R1,R0
 MOV R0,#12
 SWI &2000C ; XOS_GBPB
 MOVVS R3,#0
 CMP R3,#1
 MOVEQ R0,R4
 MVNNE R0,#0
 LDMFD sp!,{R1-R6,pc}

So the value of the unknown "offset" is returned to be tested
and possibly stored for the next call by the wrapper code that
realizes the iterator. This (in c.riscoslib in the RiscLua sources)
is

static int rdir_iter (lua_State *L);
#define RDIR_BUFLEN 256
static char rdir_buf[RDIR_BUFLEN];

static int rdir_read  (lua_State *L) {   /* the iterator */
   lua_pushinteger(L,0);
   lua_pushstring(L,lua_tostring(L,1));
   lua_pushcclosure(L,&rdir_iter,2);
   return 1;
}

static int rdir_iter (lua_State *L) {
 int *ft = (int *)rdir_buf;
 int offset = (int) lua_tointeger(L,lua_upvalueindex(1));
 const char * dir = lua_tostring(L,lua_upvalueindex(2));
 int n = rdir(dir,rdir_buf,RDIR_BUFLEN,offset);  /* new offset */
 if  (n == -1) {  /* finished */
    lua_pushnil(L);
    return 1;
               }
 else {
    lua_pushinteger(L, n);
    lua_replace(L,lua_upvalueindex(1));  /* modify iterator state */
    lua_pushstring(L,rdir_buf+24);       /* return leaf name */
    lua_pushinteger(L,ft[5]);            /* return filetype */
    return 2;
      }
}  

The returned offset is the value of "n", which, if it does not
indicate completion ( n == -1 ), updates ( see the line
        lua_replace(L,lua_upvalueindex(1)); )
an "upvalue" of the iterator - that is to say a slot in the function's
environment table. Such slots are not directly readable by the
user. Environments for functions are not features of every
programming language (e.g. C no, Pascal yes). My point is that the
mechanisms available for preserving state (in this case the "offset" 
in R4) rather depend on the kind of high level language that one is
using. In this case state is preserved across co-routine yields,
but across Wimp_Polls (an external coroutine, sort of?) - how could it be?
Especially as another task could have deleted the directory in
question before the Wimp_Poll returns. Note that rdir just returns
the termination value, -1, when XOS_GBPB returns an error. 
 
-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

[toc] | [prev] | [next] | [standalone]

#1493

On Sun, 11 Mar 2012 18:25:41 GMT, Gavin Wraith 
<gavin@wra1th.plus.com> wrote:

>> The big problem I see is that the file system does not have a 
>> mechanism to preserve state across polls.
> Surely that should be up to the application that is doing the 
polling,
> or have I misconstrued what you are saying?

You have misconstrued.

Your app does a partial OS_GBPB to read an epic list of files (say, 
the contents of a well stocked manga scanlation folder). For speed, 
it'll do them twenty at a time.

What happens if:
1. Something else does an OS_GBPB, especially if within the same 
directory structure?

2. The list of files *changes* in between polls, like you're counting 
and moving the same stuff at the same time?

While you as an application need to keep track of your own state, the 
filesystem hands you a value in R4 of OS_GBPB 12 which may not be 
valid at some indeterminate time in the future...


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1496

In message <almarsoft.8991976711320644983@news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> Your app does a partial OS_GBPB to read an epic list of files (say, 
> the contents of a well stocked manga scanlation folder). For speed, 
> it'll do them twenty at a time.
> 
> What happens if:
> 1. Something else does an OS_GBPB, especially if within the same 
> directory structure?
> 
> 2. The list of files *changes* in between polls, like you're counting 
> and moving the same stuff at the same time?
> 
> While you as an application need to keep track of your own state, the 
> filesystem hands you a value in R4 of OS_GBPB 12 which may not be 
> valid at some indeterminate time in the future...

I do not think we are in disagreement. I cannot see how any filing
operations (or access to any mutable shared resource) can be 
multitasked unless there is some locking semaphore. I do not know what 
RISC OS does about this. Can anybody more knowledgeable give a quick answer?

-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

[toc] | [prev] | [next] | [standalone]

#1498

In message <5fa2466f52.wra1th@wra1th.plus.com>
          Gavin Wraith <gavin@wra1th.plus.com> wrote:

> In message <almarsoft.8991976711320644983@news.orange.fr>
>           Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

>> Your app does a partial OS_GBPB to read an epic list of files (say,
>> the contents of a well stocked manga scanlation folder). For speed,
>> it'll do them twenty at a time.
>> 
>> What happens if:
>> 1. Something else does an OS_GBPB, especially if within the same
>> directory structure?
>> 
>> 2. The list of files *changes* in between polls, like you're counting
>> and moving the same stuff at the same time?
>> 
>> While you as an application need to keep track of your own state, the
>> filesystem hands you a value in R4 of OS_GBPB 12 which may not be
>> valid at some indeterminate time in the future...

> I do not think we are in disagreement. I cannot see how any filing
> operations (or access to any mutable shared resource) can be
> multitasked unless there is some locking semaphore. I do not know what
> RISC OS does about this. Can anybody more knowledgeable give a quick answer?

You are fully right, filing system operations can only be safely 
multitasked with semaphores, but RISC OS does not have any locking 
mechanism. It could not because all operations are blocking, so an 
operation has to succeed or fail immediately, it cannot wait.

The simple conclusion is that multitasked filing system operations are 
not safe in a transactional sense. But then, if you wanted that, you 
would not use a RISC OS filing system.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1499

On 12/03/2012 11:56, Gavin Wraith wrote:
>  I cannot see how any filing
> operations (or access to any mutable shared resource) can be
> multitasked unless there is some locking semaphore. I do not know what
> RISC OS does about this. Can anybody more knowledgeable give a quick answer?

It's quite simple; RISC OS doesn't multi-task in the true sense of the word.

It only has a single global state, which means it's essentially single 
tasking OS. Its only the Window manager bolted over the top of it, which 
allows applications to hand over control to each other in a co-operative 
way.

It's up to applications to prevent the single tasking OS from becoming 
confused by not attempting to span multi-part API calls over changes in 
control (Wimp Polls), and relying on the state still being valid.

Other OS's hold a separate state for every task (or thread) to allow 
multiple applications to preform mult-part APIs with no interference 
between them.

It's this statefulness which allows pre-emptive multi-tasking, 
multi-threading and resource protection, all of which make a grown up OS.

---druck

[toc] | [prev] | [next] | [standalone]

#1500

In message <jjlo0c$apo$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 12/03/2012 11:56, Gavin Wraith wrote:
>>  I cannot see how any filing
>> operations (or access to any mutable shared resource) can be
>> multitasked unless there is some locking semaphore. I do not know what
>> RISC OS does about this. Can anybody more knowledgeable give a quick answer?

> It's quite simple; RISC OS doesn't multi-task in the true sense of the word.

> It only has a single global state, which means it's essentially single
> tasking OS. Its only the Window manager bolted over the top of it, which
> allows applications to hand over control to each other in a co-operative
> way.

> It's up to applications to prevent the single tasking OS from becoming
> confused by not attempting to span multi-part API calls over changes in
> control (Wimp Polls), and relying on the state still being valid.

> Other OS's hold a separate state for every task (or thread) to allow
> multiple applications to preform mult-part APIs with no interference
> between them.

> It's this statefulness which allows pre-emptive multi-tasking,
> multi-threading and resource protection, all of which make a grown up OS.

True for certain other areas of RISC OS, but what you write does not 
apply to the API we are discussing here. The OS_GBPB 12 API would work 
equally well in a pre-emptive environment, precisely because it has a 
state parameter.

There are RISC OS APIs that would require extra compatibility layers 
to work in a pre-emptive environment because the state is not explicit 
but held inside RISC OS, most notably the VDU system and some Font 
calls (e.g., Font_Future font).

Niklaus Weiss faced this problem when writing DeskDebug - the 
multi-tasking debugger that runs in the desktop. As far as the 
debugged program is concerned, this is like pre-emptive multi-tasking, 
and it is close to a miracle that you can single step through redraw 
loops with VDU and Font calls while the multi-tasking RISC OS desktop 
is fully active.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1504

On Mon, 12 Mar 2012 20:57:50 +0000, druck <news@druck.org.uk> wrote:

> Other OS's hold a separate state for every task (or thread) to 
allow 
> multiple applications to preform mult-part APIs with no 
interference 

It shouldn't be hard for the kernel to allocate a "state" buffer that 
can be filled in when stuff like this is ongoing.

Though... We are dealing with a window manager that needs to be 
*told* to save FP state across polls. 


> It's this statefulness which allows pre-emptive multi-tasking,

Can be done under RISC OS. Perhaps part of the problem is some 
software is not able to cope with such behaviour (look at the printer 
mechanism).
 

> multi-threading

Isn't multi-threading just running different task code in the same 
workspace? After all, the processor can only do one thing at a 
time...

That said, the sort of stuff multi-threading is useful for (sound and 
video codec side by side) would probably be implemented under RISC OS 
as a module running off timers, interrupts, and events.


> and resource protection,

Well, we all know RISC OS is something of a pile of fail in this 
department. It's lovely to OS_EnterOS to poke hardware for fun or 
deving, but on a desktop class OS, it shouldn't be possible to kill 
the system with a single line of BASIC.


> all of which make a grown up OS.

Well, that depends on how you define grown up. RISC OS sucks in some 
ways, but is (was?) well ahead of the game in others.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1505

druck wrote:
> Gavin Wraith wrote:
> > I cannot see how any filing
> > operations (or access to any mutable shared resource) can be
> > multitasked unless there is some locking semaphore.
>
> It's quite simple; RISC OS doesn't multi-task in the true sense of the word.

It's not even RISC OS specific. ANY system where some other process
can modify the contents of a directory while another process is
scanning it will bump into this issue. It happens on Unix, it happens
on Windows. Even on a BBC B with DFS (that goes 0, 7, 15, 23, 31 !)
can have this issue if you physically remove the disk, modify it,
and replace it.

"R4 is an opaque value" has come up loads of times before on here,
as has "FilerAction is broken", it has even suggested several times
that it go in the FAQ it being such a frequent AQ.

It's along-standing bug, *WIPE in ANFS 4.xx on the BBC Master
decrements the index after deleting. It's just lucky that the
NFS's *WIPE command is only used if NFS is the current filing
system, and most (but not all) file servers happen to return
0,1,2,3,etc.

JGH

[toc] | [prev] | [next] | [standalone]

#1501

In message <almarsoft.6587021169203963779@news.orange.fr>
 on 11 Mar 2012 Rick Murray  wrote:
 
> 1. Tweak FilerAction to remember past results of R4 and not assume 
> what future should be (other than as specified in the call)
> Or:
> 2. Amend the documentation to state that this behaviour happens.
> 
> The second is option is heinous. The first is really non-optimal but 
> at least more logical than subtracting one.
> 
> The second option *could* be dealt with by some filing systems - like 
> the poster who used R4 as an offset, simply take R4 and multiply by 
> 32 (well, MOV with LSL) to turn the number into the offset desired.

In the case of CP/M discs (again, merely an example, as I realise they're
little used) just multiplying by 32 is not sufficient.  Like FAT format
discs, CP/M's directories have a number of slots to describe files, and if a
file is deleted, the slot just marked with a value to signify it can be
reused.

FilerAction currently expects R4 to increase from 0 to 1, 2, 3, 4, 5 ..., -1
and subtracts one from the value to go back a step.

Imagine you had the following set of directory entries:

File1
File2
DELETED
File3
DELETED
File4
File5

To keep FilerAction happy it seems to me that you need to return R4=3 when
you return the details for File3, and R4=4 when returning details for File4. 
But suppose before the next call to OS_GBPB that another application creates
an additional file in the directory.  The filing system would probably be
implemented to make use of the first DELETED slot, in which case, any caller
passing in R4=3 would get File3 again!  The filing system cannot remember
that the caller is expecting File4 next and adjust itself internally, as
calls to OS_GBPB have no context other than R4.  I suppose you might do
something very fiddly, and use the top 16 bits of R4 to give some context to
the filing system, which could then internally adjust the meaning of the rest
of R4 for that caller through some redirection table, but that's
nightmarish, and how does the filing system know when to throw away that
redirection?  Callers are not obliged to read the whole directory till R4 is
returned as -1.

So for CP/M and FAT it's simply impractical to implement R4 as an index of
the currently active directory slots, as files can get inserted.  Indeed, I'm
not sure this is really practical in FileCore format either, as files can be
inserted because of the way FileCore keeps things in alphabetical order.  But
perhaps FilerAction is using its internal knowledge of FileCore to cope with
this?  The problem is that it cannot have internal knowledge of all filing
systems.

It is quite conceivable that a filing system might be implemented where the
R4 value which is returned is a pointer to an internal structure where more
complicated information is kept than can be fitted into a 32-bit word.  With
such a filing system, on entry with R4=0 the filing system would commence the
traversal of the directory, create the structure and return the pointer in
R4.  On subsequent calls it would return file information, and return the
*same* value in R4.  Finally, R4 would be returned with -1.

I cannot see how other filing systems, in general, could be rewritten to work
with FilerAction's current needs without imposing dreadful constraints on
filing system authors.

So I suppose the question is, in what circumstances is FilerAction doing this
arithmetic on R4?  It must think a file has been removed from earlier in the
directory for it to need to go back a step.  Does this occur during Move and
Delete operations, then?  Chris Johnson mentions SyncDiscs.  Copy operations
might be unaffected, but wipe might run into trouble if there were more than
twenty files to wipe from a FAT32 disc at a time.

Surely to fix this problem, FilerAction would have to read a complete
directory in one go into an internal list, and then work through it, say
first dealing with all the files, and then recursing into each directory in
turn.  I can't see any other robust way out of it.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1506

On Tue, 13 Mar 2012 07:34:59 GMT, Matthew Phillips 
<spam2011m@yahoo.co.uk> wrote:

> file is deleted, the slot just marked with a value to signify it 
can be
> reused

Good call, yes. I forgot DOS-like discs did that.


> I suppose you might do something very fiddly, and use the top 16 
bits
> of R4 to give some context to the filing system,

Argh! We ought to learn the lesson of what a mistake it was to stuff 
flags and such into disc addresses. Okay, a drive that size was not 
really thought of when RISC OS was created...but surely it takes more 
trouble to stuff the data into a single register and then unpack it 
in the FS code...than if the extra info was just passed in a separate 
register?


> perhaps FilerAction is using its internal knowledge of FileCore to 
cope with

At a brief look, it is kinda complicated, though I wonder if the 
problem isn't arising from delete_next_node (in listfiles.c) where we 
have offset_to_next_item-- and perhaps the FilerAction is using this 
to pass to OS_GBPB instead of remembering the R4?


> Surely to fix this problem, FilerAction would have to read a 
complete
> directory in one go into an internal list, and then work through 
it, say
> first dealing with all the files, and then recursing into each 
directory

That's how I'd do it - scan *all* directories and subdirectories 
making an index of directories. Then start moving or deleting them 
from the deepest up, reading actual directory contents as the 
directory is encountered. This may be suboptimal for floppies or 
Econet; but we've moved on...

[plus, it isn't within the realms of possibility for it to trap and 
be aware of filesystem activity in other tasks]


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.acorn.programmer

csiph-web