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

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

Task Obey madness

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

Contents

  Task Obey madness Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-07-04 21:44 +0100
    Re: Task Obey madness Vince M Hudd <vinceh@softrock.co.uk> - 2011-07-04 22:35 +0100
      Re: Task Obey madness "John Williams (News)" <UCEbin@tiscali.co.uk> - 2011-07-05 08:07 +0200
        Re: Task Obey madness Rob Davison <nospamthanks@invalid.invalid> - 2011-07-05 19:59 +1200
          Re: Task Obey madness Paul Sprangers <Paul@sprie.nl> - 2011-07-05 10:28 +0200
            Re: Task Obey madness "John Williams (News)" <UCEbin@tiscali.co.uk> - 2011-07-05 12:08 +0200
            Re: Task Obey madness Vince M Hudd <vinceh@softrock.co.uk> - 2011-07-05 11:36 +0100
              Re: Task Obey madness Paul Sprangers <Paul@sprie.nl> - 2011-07-05 12:43 +0200
                Re: Task Obey madness "John Williams (News)" <UCEbin@tiscali.co.uk> - 2011-07-05 12:51 +0200
                  Re: Task Obey madness Ian Hamilton <Ian.Hamilton@AAUG.net> - 2011-07-05 12:03 +0100
                    Re: Task Obey madness "John Williams (News)" <UCEbin@tiscali.co.uk> - 2011-07-05 13:32 +0200
                      Re: Task Obey madness Vince M Hudd <vinceh@softrock.co.uk> - 2011-07-05 12:57 +0100
                        Re: Task Obey madness "John Williams (News)" <UCEbin@tiscali.co.uk> - 2011-07-05 14:17 +0200
                  Re: Task Obey madness Paul Sprangers <Paul@sprie.nl> - 2011-07-05 14:39 +0200
                Re: Task Obey madness Vince M Hudd <vinceh@softrock.co.uk> - 2011-07-05 12:22 +0100
            Re: Task Obey madness Rob Davison <nospamthanks@invalid.invalid> - 2011-07-06 08:27 +1200
            Re: Task Obey madness Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-07-06 08:15 +0200
              Re: Task Obey madness jgharston <jgh@arcade.demon.co.uk> - 2011-07-06 18:48 -0700
                Re: Task Obey madness "Ste (news)" <steve@revi11.plus.com> - 2011-07-07 13:55 +0100
                Re: Task Obey madness Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-07-12 20:07 +0200
        Re: Task Obey madness cferris@freeRemoveuk.com.invalid - 2011-07-05 09:09 +0100
          Re: Task Obey madness Steve Drain <steve@kappa.me.uk> - 2011-07-05 10:19 +0100
      Re: Task Obey madness Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-07-05 12:40 +0100
        Re: Task Obey madness Martin <News03@avisoft.f9.co.uk> - 2011-07-05 16:19 +0100
          Re: Task Obey madness Alan Adams <alan@adamshome.org.uk> - 2011-07-05 17:31 +0100
            Re: Task Obey madness Ian J Hartley <Ian.Hartley@sky.com> - 2011-07-06 12:35 +0100
              Re: Task Obey madness "Ste (news)" <steve@revi11.plus.com> - 2011-07-07 13:57 +0100
                Re: Task Obey madness Alan Adams <alan@adamshome.org.uk> - 2011-07-07 21:18 +0100
                Re: Task Obey madness Ian J Hartley <Ian.Hartley@sky.com> - 2011-07-13 12:36 +0100
                  Re: Task Obey madness "Ste (news)" <steve@revi11.plus.com> - 2011-07-14 15:58 +0100
                    Re: Task Obey madness Ian Hamilton <Ian.Hamilton@AAUG.net> - 2011-07-14 16:10 +0100
                    Re: Task Obey madness Ian J Hartley <Ian.Hartley@sky.com> - 2011-07-17 12:30 +0100
                      Re: Task Obey madness "Ste (news)" <steve@revi11.plus.com> - 2011-07-17 14:23 +0100
                        Re: Task Obey madness Ian J Hartley <Ian.Hartley@sky.com> - 2011-07-17 16:14 +0100
                  Re: Task Obey madness druck <news@druck.org.uk> - 2011-07-14 19:23 +0100
                    Re: Task Obey madness Ian J Hartley <Ian.Hartley@sky.com> - 2011-07-17 14:17 +0100
    Re: Task Obey madness Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2011-07-05 22:15 +0100
      Re: Task Obey madness Rainer Schubert <dl6hbo@dl6hbo.inka.de> - 2011-07-08 17:14 +0200

Page 1 of 2  [1] 2  Next page →

#500 — Task Obey madness

This is a most peculiar set of symptoms which I've never experienced
before a couple of weeks ago, but which I've now experienced on both RO5
and RO6.

I have a command-line BASIC program which converts from one file format
to another.  In the process it opens two more, temporary, files in the
same directory as the output, which it deletes when the process is
complete.  I batch-convert a lot of files in one go by means of a Task
Obey script, which does not produce any VDU output.  This normally runs
as expected.  However, sometimes it doesn't...

Very occasionally, the Task Obey will stop partway down with a "This
file is already open" error.  The cause is random, and certainly not
caused by any open files.  The last time it happened, I was running two
different Task Obeys at once, outputting into different directories and
getting input from the same directory, but this shouldn't have made a
difference, as input-only files are allowed to be opened any number of
times, and all I was doing was one call to OS_File 16.  It's also
occurred when I was only running one instance.

What happens next seems equally random.  On one occasion, immediately
after giving the error, the Task Obey then skated drunkenly down all the
remaining star-commands in the file, executed about 30% of them
completely at random, and then forcibly terminated them all, leaving a
large assortment of temporary files still open.  I cannot possibly
imagine what could have caused this unique and demented behaviour.

Just now, the Task Obey simply terminated after giving the error, but
left its sister still running successfully.  Wondering if I could
reproduce it, I decided to run the crashed script again (with the other
one still going), but I mistakenly ran another instance of the uncrashed
script instead of restarting the crashed one.  Whoops, thought I, and
took to the Task Manager to rectify the situation.

When I selected 'Quit' for what I assumed was the new task (although it
may have been the old one), the computer locked up for about thirty
seconds, frantically thrashing the hard disc.  When the task finally
exited and I got control back, I discovered why.  Inside the output
directory were hundreds of temporary files, all completely blank, all
still open, for every single input file specified on every line in the
Task Obey file, up to a certain line - which I later learnt was due to
the fact that at that point it had run out of file handles.  Not that it
complained it had run out of file handles - it simply exited silently
without doing anything else, which was of course what it was supposed to
have done in the first bloody place.

Now, let's get one thing quite clear.  The Task Obey does not open any
files.  The Task Obey is nothing more than a list of start-commands, all
calling the BASIC file for different input values (via an alias to take
out the repetitive bits).  All OPENOUT commands are in the BASIC file,
and quite deep within the BASIC file at that.  In order to open each two
of those temporary files, the Task Obey must have executed each of its
remaining lines, processed the alias, and called the BASIC file with the
correct parameters for each one.  The BASIC file must then have
validated its parameters, loaded the input file into memory, interpreted
and generated quite a large number of complex data structures, done an
entire first pass over most of the input data to define variable limits,
and DIMensioned an ungodly number of arrays, before it even got close to
the output procedure in which the two temporary files were created.
(The final files, which didn't appear, are left until after the
temporary files are finished.)  And since it isn't that long after the
creation that the first bytes of output are written, the Task Obey must
have seeked through the whole (not inconsiderable) initialisation
process until it discovered two OPENOUT commands, after which it
immediately moved onto the next input command, without going through the
automatic closure in the error handler or indeed generating an error.

What caused this?  I do not have a clue.  It is the single most bizarre
thing I have observed RISC OS do, and in my time as a programmer, I've
seen it do many.

Does anyone have any idea what was going on at all?  Especially WRT the
earlier incident, in which only some non-consecutive lines in the script
were executed?  Furthermore, does anyone have any idea what may cause a
program to throw a "This file is already open" error for no reason at
all?

-- 
  __<^>__   "Start off every day with a smile and get it over with."
 / _   _ \  - W.C. Fields
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [next] | [standalone]

#501

Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:

> This is a most peculiar set of symptoms which I've never experienced
> before a couple of weeks ago, but which I've now experienced on both RO5
> and RO6.

I'm inclined to say that what you're seeing is a classic 'close all'
symptom. i.e. it looks like *something* on your system(s) is trying to close
a file with a handle of 0.

I'd start by checking the programs involved: You mention where the OPENOUT
commands are - but what about the CLOSE commands? Are they equally 'deep' in
the BASIC and are you absolutely sure one isn't being issued where an
equivalent OPENOUT hasn't already been issued, so the handle is therefore 0?
Throw sensible checks around any CLOSE commands - only issue the CLOSE if
the handle isn't 0 (and then set that handle *to* 0).

Having said that, it doesn't necessarily have to be the programs you are
experiencing problems with that are doing this - it could be something else
entirely; What else changed around the time the problem started - did you
install anything at that point?

[...]

-- 
Soft Rock Software:                   http://www.softrock.co.uk
Vince M Hudd:                         http://misc.vinceh.com/about-vinceh/

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

#502

In article <mpro.lntvzt002odox02pg.vinceh@softrock.co.uk>,
   Vince M Hudd <vinceh@softrock.co.uk> wrote:

> Throw sensible checks around any CLOSE commands - only issue the CLOSE if
> the handle isn't 0 (and then set that handle *to* 0).

I particularly agree with that bit that Vince offers. So I'll repeat it for
emphasis

Only close a file if the handle is not zero, and when you do, set the
handle to zero.  Make it a habit!

Do the same particularly in your error routine.

John

-- 
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

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

#503

On 7/5/2011 6:07 PM, John Williams (News) wrote:

> Only close a file if the handle is not zero, and when you do, set the
> handle to zero.  Make it a habit!
>
> Do the same particularly in your error routine.

I'll third the above advice. Always prefix any attempt to close
a file handle with a check to ensure it is non-zero.

In error handlers something along the lines of...

IF handle%<>0 THEN htemp%=handle%:handle%=0:CLOSE#htemp%

...is better than:

IF handle%<>0 THEN CLOSE#handle%:handle%=0


Rob.
-- 
Maple Glen  http://www.mapleglen.co.nz/
Photos      http://www.pbase.com/mapleglen/

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

#505

In article <iuugf2$u4e$1@dont-email.me>,
   Rob Davison <nospamthanks@invalid.invalid> wrote:

> > Only close a file if the handle is not zero, and when you do, set the
> > handle to zero.  Make it a habit!

I will join the fellow thinkers on this rule.
For many years I had repeating problems, especially with fonts, until a
certain M. W. from Germany pointed at the CLOSE#0 pitfall.

But...

> IF handle%<>0 THEN htemp%=handle%:handle%=0:CLOSE#htemp%

> ...is better than:

> IF handle%<>0 THEN CLOSE#handle%:handle%=0

why exactly is that better?
And exactly why has the handle% to be set to 0 at all?

Kind regards,
Paul Sprangers

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

#507

In article <51edf0d282Paul@sprie.nl>,
   Paul Sprangers <Paul@sprie.nl> wrote:

> why has the handle% to be set to 0 at all?

In case it's tested subsequently - then we know not to attempt to close it.

It's a bit chicken/egg, and may not always be absolutely necessary, but if
you do that, nothing can go wrong.  Like I suggested, a good habit to get
into!

I think it was Adny Holdsworth who suggested it to me, long, long ago.
Probably in the very early development of Pic_Index.

John

-- 
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

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

#509

Paul Sprangers <Paul@sprie.nl> wrote:

[...]

> And exactly why has the handle% to be set to 0 at all?

When you close a file, the file handle becomes available again for a
subsequent open - be that by your program or another.

If the variable containing the handle isn't zeroed, what happens if the
close function is called again with that same variable? Answer: You might
close a file that's been opened by something else. A similar problem to
CLOSE#0, except only affecting one open file (and the program that opened
it).

-- 
Soft Rock Software:                   http://www.softrock.co.uk
Vince M Hudd:                         http://misc.vinceh.com/about-vinceh/

Cash prize for USB audio:             http://www.riscository.com/?p=261
OI! RISCOSitory - read all about it!  http://www.riscository.com/?p=248

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

#510

In article <mpro.lnuw4c001s9zb01fg.vinceh@softrock.co.uk>,
   Vince M Hudd <vinceh@softrock.co.uk> wrote:

> If the variable containing the handle isn't zeroed, what happens if the
> close function is called again with that same variable? Answer: You might
> close a file that's been opened by something else.

But if the variable IS zeroed, and is called again by a close function,
wouldn't we have CLOSE#0 in fact again?

Kind regards,
Paul Sprangers

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

#511

In article <51edfd1bcePaul@sprie.nl>,
   Paul Sprangers <Paul@sprie.nl> wrote:

> But if the variable IS zeroed, and is called again by a close function,
> wouldn't we have CLOSE#0 in fact again?

Only if you attempt to close it without checking again that it's not zero.

        REM File closing
        DEF PROC_Close(handle%)
        IF handle%<>0 CLOSE#handle%
        handle%=0
        ENDPROC

If you used that, it couldn't happen.

John

-- 
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

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

#512

In article <51edfde787UCEbin@tiscali.co.uk>,
   John Williams (News) <UCEbin@tiscali.co.uk> wrote:
> In article <51edfd1bcePaul@sprie.nl>,
>    Paul Sprangers <Paul@sprie.nl> wrote:

> > But if the variable IS zeroed, and is called again by a close
> > function, wouldn't we have CLOSE#0 in fact again?

> Only if you attempt to close it without checking again that it's not
> zero.

>         REM File closing
>         DEF PROC_Close(handle%)

That line should be :-

          DEF PROC_Close(RETURN handle%)

handle% is LOCAL otherwise%

>         IF handle%<>0 CLOSE#handle%
>         handle%=0
>         ENDPROC

> If you used that, it couldn't happen.

Ian

-- 
Ian Hamilton (Iyonix RO5)  http://www.hamiltoni.pwp.blueyonder.co.uk/

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

#514

In article <51edff01b3Ian.Hamilton@AAUG.Net>,
   Ian Hamilton <Ian.Hamilton@AAUG.net> wrote:

> That line should be :-

>           DEF PROC_Close(RETURN handle%)

> handle% is LOCAL otherwise%

Works fine as it is.  The local handle% is assigned by the call to the
value of the actual handle you put inside the brackets in your call, the
file is closed, and then handle% is no longer required and can be
discarded/ignored until reassigned by a subsequent call.

John

-- 
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

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

#516

"John Williams (News)" <UCEbin@tiscali.co.uk> wrote:

> In article <51edff01b3Ian.Hamilton@AAUG.Net>,
>    Ian Hamilton <Ian.Hamilton@AAUG.net> wrote:

> > That line should be :-

> >           DEF PROC_Close(RETURN handle%)

> > handle% is LOCAL otherwise%

> Works fine as it is.

No it doesn't! Ian is quite correct.

> The local handle% is assigned by the call to the value of the actual
> handle you put inside the brackets in your call, the file is closed, and
> then handle% is no longer required and can be discarded/ignored until
> reassigned by a subsequent call.

The point is, you've only zeroed the LOCAL variable. After calling your
procedure, the *original* variable containing the file handle still contains
the same value.

Consider the following example. I'm using your close routine, but with PRINT
statements replacing the CLOSE, and simply assigning a value to my file
handle variable instead of actually opening a file. This will therefore be
safe to try:

----8<----
REM Open a file (assign a value as a pretend file handle..)
handle% = 1

REM Do some stuff with the file, and then...
PROC_Close(handle%)

REM The file is now closed... but wait! What happens if we accidentally...
PROC_Close(handle%)

END

REM File closing
DEF PROC_Close(handle%)
 IF handle%<>0 PRINT" Closing ";handle%
 handle%=0
ENDPROC
----8<----

The output from running that will probably be:

>RUN
 Closing 1
 Closing 1
>

And the reason is that you only zeroed the LOCAL handle% - which means the
variable containing that handle outwith the procedure was unaffected. The
zero needs to be *returned* so that the original handle is zeroed.

Just throwing in that RETURN to make it DEF PROC_Close(RETURN handle%) takes
care of it. The output should then be the more desirable:

>RUN
 Closing 1
>

Caveat: This is usenet, so it's untested. It's a rule.

-- 
Soft Rock Software:                   http://www.softrock.co.uk
Vince M Hudd:                         http://misc.vinceh.com/about-vinceh/

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

#517

In article <mpro.lnuzvd001pwr304o8.vinceh@softrock.co.uk>, Vince M Hudd
<vinceh@softrock.co.uk> wrote:

> The point is, you've only zeroed the LOCAL variable. After calling your
> procedure, the *original* variable containing the file handle still
> contains the same value.

OK - apologies all round.

John

-- 
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

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

#518

In article <51edfde787UCEbin@tiscali.co.uk>,
   John Williams (News) <UCEbin@tiscali.co.uk> wrote:

> > But if the variable IS zeroed, and is called again by a close function,
> > wouldn't we have CLOSE#0 in fact again?

> Only if you attempt to close it without checking again that it's not
> zero.

Ah yes, of course. Brains are getting sluggish. Apologise.

Kind regards,
Paul Sprangers

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

#513

Paul Sprangers <Paul@sprie.nl> wrote:
> In article <mpro.lnuw4c001s9zb01fg.vinceh@softrock.co.uk>,
>    Vince M Hudd <vinceh@softrock.co.uk> wrote:
 
> > If the variable containing the handle isn't zeroed, what happens if the
> > close function is called again with that same variable? Answer: You
> > might close a file that's been opened by something else.
 
> But if the variable IS zeroed, and is called again by a close function,
> wouldn't we have CLOSE#0 in fact again?

Not if the close is preceeded by a check for the handle being zero - the
important point is, as I stated in my original reply to Martin, to do *both*
things in any close function.

 1) Check that the variable containing the handle is not zero - if it is 
    zero, *do not close the file*.

 2) After closing the file, zero the variable.

 #1 prevents the accidental closing of ALL files if the close routine is
    called with a variable containing 0.

 #2 prevents the accidental closing of another program's file if the close
    routine is called again with a variable containing the same handle as
    before.

-- 
Soft Rock Software:                   http://www.softrock.co.uk
Vince M Hudd:                         http://misc.vinceh.com/about-vinceh/

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

#521

On 7/5/2011 8:28 PM, Paul Sprangers wrote:
> In article<iuugf2$u4e$1@dont-email.me>,
>     Rob Davison<nospamthanks@invalid.invalid>  wrote:

>> IF handle%<>0 THEN htemp%=handle%:handle%=0:CLOSE#htemp%
>
>> ...is better than:
>
>> IF handle%<>0 THEN CLOSE#handle%:handle%=0
>
> why exactly is that better?

Consider what might happen if the CLOSE# causes an(other) error.

> And exactly why has the handle% to be set to 0 at all?

Answered by everyone else!


Rob.
-- 
Maple Glen  http://www.mapleglen.co.nz/
Photos      http://www.pbase.com/mapleglen/

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

#523

On 05/07/2011 10:28, Paul Sprangers wrote:

>> IF handle%<>0 THEN htemp%=handle%:handle%=0:CLOSE#htemp%
>> ...is better than:
>> IF handle%<>0 THEN CLOSE#handle%:handle%=0

> why exactly is that better?

No idea. It seems excessive to me.


> And exactly why has the handle% to be set to 0 at all?

To mark it as having been "closed", so you:

* don't run the risk of closing a closed file

and:

* can safely use that handle elsewhere (actually, unlike VB, you don't
   get a choice as the OS assigns the handle to you) without worrying
   about it being closed by something else somewhere else (perhaps even
   in a different program).


BTW, +1 on the advice.


Best wishes,

Rick.

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

#525

Rick Murray wrote:
> >> IF handle%<>0 THEN htemp%=handle%:handle%=0:CLOSE#htemp%
> >> ...is better than:
> >> IF handle%<>0 THEN CLOSE#handle%:handle%=0
> > why exactly is that better?
>
> No idea. It seems excessive to me.

Consider what happens if the CLOSE# causes an error, particularly
in conjunction with

ON ERROR PROCclose....

See http://bb4w.wikispaces.com/Forcing+a+variable+to+exist

JGH

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

#526

In article
<97b8a439-e653-4c26-abe2-b759d2760fc0@r2g2000vbj.googlegroups.com>,
   jgharston <jgh@arcade.demon.co.uk> wrote:
> Rick Murray wrote:
> > >> IF handle%<>0 THEN htemp%=handle%:handle%=0:CLOSE#htemp%
> > >> ...is better than:
> > >> IF handle%<>0 THEN CLOSE#handle%:handle%=0
> > > why exactly is that better?
> >
> > No idea. It seems excessive to me.
>
> Consider what happens if the CLOSE# causes an error

There are two reasons why you might not want to do that:

1. most half-decent BASIC error handlers will look like this:

  DEF PROCerror
    ON ERROR OFF
    ...
  ENDPROC

  or something like that, so if there's an error when the file is closed, you
  won't end up calling the routine to try to close the file again anyway.

2. if the CLOSE# itself returned an error then that _could_ indicate that 
  some transient event has stopped your close operation from working in which
  case there's no harm in keeping the handle in a variable and trying again
  later to close the file.

On the whole, it all depends upon whether your program is expecting to keep
running after an error or just tidy up as best it can and then report the
error.

However, clearing the handle variable before attempting the CLOSE# call is
also compelling for other reasons (such as the case where you're attempting
to close the file for normal reasons, rather than because of an error).

So it's horses for courses.

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

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

#549

On 07/07/2011 03:48, jgharston wrote:

> See http://bb4w.wikispaces.com/Forcing+a+variable+to+exist

Ah, I see. To make the variable exist so attempting to close doesn't 
fault it if the variable hadn't been defined as of that point.

Oddly, I've never run into this. I guess I must use LOCAL ERROR a lot. ;-)


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