[clean-list] sfopen sorrows?

[Marco Kesseler]

On May 31, 2006, at 4:32 PM, John van Groningen wrote:

>
> Philippos Apolinarius wrote:
>> I don't know how to pose my problem, since I know very little about
>> programming. I am preparing myself to take admission examinations to
>> universities around the world (SAT, SATII and the like), and also
>> proficiency in Chinese. As everybody else in the same situation, I
>> use Flash Cards. The Flash Card managerial programs that I happen to
>> use are written in Clean.  The Flash Card programs use the
>> Functional Fragments to read things like JPG, PDF, compress stuff,
>> etc. After using the program for some time (say, two hours), sfopen
>> complains that there is an "IOError: sfopen: Too many files". I
>> would like to know how to increase the number of files that sfopen
>> can open for reading.
>
> Download the source code for the runtime system, change MAX_N_FILES  
> in wfileIO3.c (windows), mfileIO3.c (mac) or ufileIO2.c (linux/ 
> solaris),
> compile a new _startup2.o (windows) or _startup.o (linux/solaris,
> for mac also _startup.xo and _startup.cxo) file and replace the
> file(s) in the Clean System Files folder of the StdEnv with the new  
> one.
>
> Files opened by sfopen cannot be closed, so instead the program  
> should use
> fopen and close files that are not used any more.

Maybe in this case, using fopen could be an option. In general  
however, changing sfopen into fopen can be a pain in the B***.

Another option might be to wait for a newer version of funlib. I have  
been experimenting on windows with building my own interface to the  
file system. This will (should?) happily keep as many files open as  
you want, that is, as long as windows returns new handles. It  
includes other goodies such as writing to a memory mapped string  
outside the heap. Anyway, I am currently planning to add similar  
functionality for OSX, as well as mapping (a subset of) the same  
interface onto stdFile, for those running on other platforms  
(obviously the latter won't offer all functionality).

By the way, for shared files it would make sense - also for StdFile -  
to close some handles from time to time. Apart from a slight  
performance penalty, it seems to me that it would not be an issue to  
reopen the file whenever a function hits a file that has been closed  
in this way. I am sure all sorts of smart paging algorithms would apply.

regards,
Marco