issues with called table causing lookup behaviour change...need help

Fairlight fairlite at fairlite.com
Fri Aug 9 14:33:44 PDT 2013


On Fri, Aug 09, 2013 at 03:46:28PM -0400, Bruce Easton thus spoke:
> It sounds like you just need to change any closes to the common file in 
> the called table to be write commands.  And if it's OK for the values 
> changed for said file by the called prc to not be written until your 
> close at the end of your loop in the main program, then you shouldn't 
> need a write nor a close in the called table.

I always follow my writes with closes if I won't be using the resource any
longer - in any language.  Yes, Perl, and even C will inherently and
automatically close files when execution ceases; that's a function of the
OS more than the language.  

It's still good practise to explicitly close files, and depending on how
low-level a language is, manually flush the file descriptor before close,
if you know close doesn't automagically do it (as Perl does).

A real gotcha is having a file open, writing, having something bad happen,
and not all the data is flushed to the file descriptor.

I try sticking to best practises, no matter what language I'm working in.
You don't technically need an 'exit' in shell scripts, but I use them for
almost all of them (sometimes I slip up).

So essentially, fP penalises you for doing things the correct way.  Lovely.

I basically stuck a global/extern variable in the top of the tables in
question, and I set it to "Y" at the top of the one that needs me not to
execute closes on those lookups, and checked that variable in the called
table as a condition for those closes being executed.  Easy fix, once you
know what the non-intuitive problem is.

I say non-intuitive, as in most languages, if you weren't dealing with
a numeric file descriptor, you'd be dealing with a named filehandle.
Either way, each instance would be a discrete instance of a connection
to the file, complete with its own open() modes, etc.  Sounds like fP
maintains seek positions for each lookup alias, and may even enforce
protect/no-protect individually (seems to), but ultimately reuses the same
file descriptor, and a close for one alias means game over for every alias
pointing to the same file.  That is in no way intuitive to anyone who's
coded in -anything- sane.  

Nobody on this planet could convince me that's sane, so let's not even
argue over it.  I'll just agree to disagree, and work around fP's broken
way of handling the situation.  Everyone else wants to believe it's cool,
fine by me.  YMMV.

mark->
-- 
Audio panton, cogito singularis.


More information about the Filepro-list mailing list