Looking at Pathalias and Xenix

[Mark E. Mallett]

In article <146 at roberta.UUCP> michael at roberta.UUCP (Michael A. Moran ) writes:
>In article <1989Jan9.134250.27793 at ateng.ateng.com>, chip at ateng.ateng.com (Chip Salzenberg) writes:
>> 
>> >I think it hits the top of memory (my system has 2048K, with 1402K as
>> >the maximum user process size) and tries to swap. Maybe it is a system bug.
>> 
>> Well, I have 3.5M.  Perhaps that's it.
>
>And you are very close to the limit where pathalias will fail.  Running Xenix
>on a '286 with 3 Megs I can build a pathalias file with about 9800 sites.
>With 2.5 Megs I can build a pathalias file with about 7500 sites.

My problem with pathalias is not in how much memory I have (by the
way, 3.5 megabytes for 11,000 nodes works out to over 300 bytes per
node: I hope that pathalias doesn't have that kind of overhead).
Recent breakdowns in my pathalias processing caused me to look at the
source.  It (pathalias) allocates symbol tables as big monolithic
arrays of pointers to elements.  When a table gets full, a bigger one
is allocated and the smaller table is copied into it.  The problem is
that my Microport System V/AT system doesn't support allocation of bigger
than 64K blocks, yet the situation has reached the point where pathalias
has tried to expand to an array that takes 84K.  Pushed into the 16
bit int for call to malloc, very bad things happen.

My though has been to try to rewrite the symbol management to accomodate
this restriction.  If anyone has already done it, please drop me a note.

I'm cross-posting this over to microport, where it probably has more
relevance (in my situation).

Thanks,
-mm-
-- 
Mark E. Mallett  Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 
Bus. Phone: 603 645 5069    Home: 603 424 8129     BIX: mmallett
uucp: mem at zinn.MV.COM  (  ...{decvax|elrond|harvard}!zinn!mem   )
Northern MA and Southern NH consultants:  Ask me about MV.COM