To Scott G.: Kernel question
Christian Hennecke
I'm in the process of adding support for the PROCESSES and
SHELLHANDLESINC statements in CONFIG.SYS to XWorkplace. The problem is
that I wasn't able to find information about limits.
Well, the lower limit for SHELLHANDLESINC is zero, obviously. Is there
an upper limit, either fixed or set by the kernel at boot depending on
the system? If the latter, how can I find out what the current limit is?
As for PROCESSES, if somebody sets too low a value the machine will
crash I guess. Is there some limit below which the kernel will ignore
the statement or report an error?
The upper limit for PROCESSES is a real problem, as it depends on the
system somehow. As long as the statement is not used, I can use
DosQuerySysInfo() to get QSV_MAXPROCESSES. When PROCESSES is in use,
however, I can't do that anymore. Could you tell me how I can compute
the value myself?
BTW, it seems that PROCESSES hasn't always been there. Could you tell me
when it was introduced?
--
"I smell blood and an era of prominent madmen." - W.H. Auden
scott g
> Well, the lower limit for SHELLHANDLESINC is zero, obviously. Is there
> an upper limit, either fixed or set by the kernel at boot depending on
> the system? If the latter, how can I find out what the current limit is?
DosSetRelMaxFH. It probably doesn't make sense to allow a number higher than
255, though I suspect that MAXINT/2 is probably conceivable.
> As for PROCESSES, if somebody sets too low a value the machine will
> crash I guess. Is there some limit below which the kernel will ignore
> the statement or report an error?
> The upper limit for PROCESSES is a real problem, as it depends on the
> system somehow. As long as the statement is not used, I can use
> DosQuerySysInfo() to get QSV_MAXPROCESSES. When PROCESSES is in use,
> however, I can't do that anymore. Could you tell me how I can compute
> the value myself?
I don't remember the details. I'll try to have a look at the source code
sometime this week.
> BTW, it seems that PROCESSES hasn't always been there. Could you tell me
> when it was introduced?
Sometime around FP13/ACP/MCP, iirc.
Christian Hennecke
<scottego...@sbcglobal.boguspart.net> wrote:
> > Well, the lower limit for SHELLHANDLESINC is zero, obviously. Is there
> > an upper limit, either fixed or set by the kernel at boot depending on
> > the system? If the latter, how can I find out what the current limit is?
> It's basically just telling the first (or was it the second?) pmshell to call
> DosSetRelMaxFH. It probably doesn't make sense to allow a number higher than
> 255, though I suspect that MAXINT/2 is probably conceivable.
OK, I'll go for 255 then.
> > As for PROCESSES, if somebody sets too low a value the machine will
> > crash I guess. Is there some limit below which the kernel will ignore
> > the statement or report an error?
> > The upper limit for PROCESSES is a real problem, as it depends on the
> > system somehow. As long as the statement is not used, I can use
> > DosQuerySysInfo() to get QSV_MAXPROCESSES. When PROCESSES is in use,
> > however, I can't do that anymore. Could you tell me how I can compute
> > the value myself?
>
> I don't remember the details. I'll try to have a look at the source code
> sometime this week.
That would be great!
Scott G.
> crash I guess. Is there some limit below which the kernel will ignore
> the statement or report an error?
If someone sets a value too low, stuff won't work. I don't really check,
since it's hard to say in general what that value is. Probably nothing
below 20 or so makes sense. For sure I disallow values > 4096, but
probably 1024 or 2048 or so is the maximum sensible value. Set it too
high and bad things will happen, anyway (out of memory conditions at least).
> The upper limit for PROCESSES is a real problem, as it depends on the
> system somehow. As long as the statement is not used, I can use
> DosQuerySysInfo() to get QSV_MAXPROCESSES. When PROCESSES is in use,
> however, I can't do that anymore. Could you tell me how I can compute
> the value myself?
Well I think that index changed from 29 to 30 somewhere along the line,
so be cautious. If it doesn't work though (and I don't know why it
wouldn't), you're out of luck. You could try messing with the theseus4
interfaces on sufficiently late kernels, but that cure is probably worse
than the disease.
Christian Hennecke
<scott...@sbcglobal.boguspart.net> wrote:
> > The upper limit for PROCESSES is a real problem, as it depends on the
> > system somehow. As long as the statement is not used, I can use
> > DosQuerySysInfo() to get QSV_MAXPROCESSES. When PROCESSES is in use,
> > however, I can't do that anymore. Could you tell me how I can compute
> > the value myself?
> Well I think that index changed from 29 to 30 somewhere along the line,
> so be cautious. If it doesn't work though (and I don't know why it
> wouldn't), you're out of luck. You could try messing with the theseus4
> interfaces on sufficiently late kernels, but that cure is probably worse
> than the disease.
Sorry, I didn't make myself clear enough. The DosQuerySysInfo() call
works in all situations. The problem is that if PROCESSES is used to
restrict the maximum number, the return value of DosQuerySysInfo() will
be that number and not the potential maximum. That's why I asked how it
is computed.
scott g
> Sorry, I didn't make myself clear enough. The DosQuerySysInfo() call
> works in all situations. The problem is that if PROCESSES is used to
> restrict the maximum number, the return value of DosQuerySysInfo() will
> be that number and not the potential maximum. That's why I asked how it is computed.
Oh, you're out of luck, there. It's a non-trivial calculation based on amount of
free memory, size of some structures, etc. Just go with the 2048 as a max and
you'll be fine.
Christian Hennecke
OK. One last question: What happens if somebody specifies a number that
is larger than what the machine can actually handle?
scott g
> OK. One last question: What happens if somebody specifies a number that
> is larger than what the machine can actually handle?
Then the kernel sets the value to the maximum possible value that fits.
Really, when I added that parameter, it was with an eye to *reducing* the
maxprocess count to something more realistic in order to save memory.