Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!jarthur!usc!samsung!munnari.oz.au!csource!david
From: david@csource.OZ.AU (david nugent)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Retrieving the value of FILES=???
Keywords: Global File Handle Table
Message-ID: <22@csource.OZ.AU>
Date: 15 Jun 90 16:12:31 GMT
References: <605@digigw.digital.co.jp>
Organization: Unique Computing Pty Ltd, Melb, Aust.
Lines: 39

In <605@digigw.digital.co.jp> gday@digigw.digital.co.jp (Gordon Day) writes:

>The only (ugly) solution that I've come up with is to perform a "consume 
>resource until failure" check where I reset the number of available 
>handles by my program to some high value and perform a dup (int 21 
>function 45) on stdin until the dup call fails.  At this point, I know 
>that the #successful dups + 5 (stdin, stdout, etc) = size of the global 
>handle table.

>Can you suggest something more elegant?


Nope.  I am aware that there is a way of doing what you want, but
I don't know it, unfortunately.

But I can certainly suggest very strongly that you don't attack
it this way.  I've known many a program to get into trouble doing this,
particularly if there's no upper limit placed on the number of files.

There do exist DOS-like environments which probably do run your software
if you didn't do the above 'trick'.  PC-MOS/386 for example; since there
IS no upper limit to the number of files it can handle (save the memory
available in the SMP, which is similar to a Unix kernel's workspace), so
a program might go "forever" opening files only to have the system crash
when the kernel runs out of SMP and isn't able to recover.

This IS a workaround in MOS - by setting the maximum number of open handles
on a task-by-task basis - but the problem which arise from that is that
it's no longer possible to increase the number of available handles.

It guess it's a trade-off, but if you at least place some ceiling on
how many files you attempt to open, that's something.  If MOS's kernel
runs out of memory as a result, you're still in trouble though.

david

-- 
         * Unique Computing Pty Ltd, Melbourne, Australia. *
       david@csource.oz.au  3:632/348@fidonet  28:4100/1@signet