Re: [Gm2] IOChan.RawRead() returns fewer bytes than available

[SiTex Graphics]

On Wed, Apr 28, 2010 at 2:26 PM, Gaius Mulley <address@hidden> wrote:
> this should work - ensure that there is a '-I.'  in the link command.
> You can double check this via 'gm2 -fmodules -c ...'

Thanks, with -I. the local version takes precedent.  Using -fmodules I
see that the libraries are stored in $HOME/opt/lib/... which is very
useful to know.  With that info I've made an interesting discovery:

First, I tried to recompile RTgen.mod with some debugging statements.

gcc -c RTgen.mod

but the compiler fails with

RTgen.mod:81:4: error: argument to DISPOSE must be a pointer

which corresponds to

PROCEDURE KillChanDev(g : GenDevIF) : GenDevIF;
BEGIN
  DISPOSE(g);
  RETURN (NIL);
END KillChanDev;

and seems like a valid complaint considering that GenDevIF is an
opaque type defined in RTgenif.def.  As a quick workaround I just
commented out the DISPOSE to get the module to compile.  Linking
against the modified .o produces an executable WITHOUT the problems
reported earlier!  I removed my debugging statements, and file IO
still seems to work fine (except that KillChanDev is not doing what it
should of course).

My guess is that one or more options used to build RTgen are causing a
runtime failure.  If there were a fix for KillChanDev, then I would
have a workaround for now.  It seems like RTgenif could expose a
routine to free a GenDevIF.

>> The current issue aside, a couple comments about FIO:
>>
>> 1.  I wish there were not a fixed limit on the number of open files.
>> I can easily imagine cases where we have more than 100 files open at
>> once.  Can the limit at least be increased to say 1000?
>
> ok sure - I'll modify this to use a dynamic array and extend the array
> as necessary.
>
>> 2.  The handling of EOF seems odd.  I'd expect EOF to be tracked as
>> part of the file status based on the last read attempt.
>
> yes - I'll change this as well..  interestingly the buffer size is
> 16*1024 so it is likely a problem in FIO..  so getting rid of the
> strange EOF might be a very good start :-)

That would be great.  If I'm following the logic correctly, the
current implementation is potentially pretty bad for random reads over
a network.  RTfio.dorbytes calls EOF() after every read, and since EOF
reads a char which triggers a buffer fill, each user read is going to
translate into at least 2 reads on the network.

Thanks,
Scott