lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV lynx 2.7.1 for Minix


From: Klaus Weide
Subject: Re: LYNX-DEV lynx 2.7.1 for Minix
Date: Wed, 15 Oct 1997 19:05:05 -0500 (CDT)

On Fri, 10 Oct 1997, Ing. Claudio M. Tantignone wrote:

> Hello:
> Thanks for your comments. The port of lynx to Minix is from the last I
> saw in Internet, 2.7.1. 

The development code, meant to become the next version of Lynx, is in
<URL:http://sol.slcc.edu/lynx/current/>.  It would be interesting to see
whether your port can be upgraded to that code base.  (No doubt it needs
some more memory than 2.7.1.)  If you can do that, it may be possible to
put the mods for Minix in the devel code.

You should probably be subscribed to lynx-dev, at least temporarily, to
better follow up on this (if that's what you want).

> >> Hello:
> >> I finished porting lynx to Minix 386. This operating system have no virtual
> >> memory
> >> so it run in little machines. 
> >
> >Are you making it available?  What version?  How much did you have to
> >change?
> 
> No yet, I will sent it to minix1.hampshire.edu this end of week. I will
> comment you when it be ready. The version I port was 2.7.1.
> 
> >What do you mean by "crashing"?  An exit(-1) via the outofmem macro or
> >something else?
> 
> No, some routine gave me the "out of memory" message. You need to set the
> stack and data size in Minix with the command chmem (native for Minix).
> So for me the program crash because it was short of memory.
>

If it looks like

    GridText.c split_line: out of memory.  Aborting...

    Memory exhausted!  Program aborted!

that IS the outofmem macro (defined in HTUtils.h).  It is used after a
malloc or calloc etc has failed.

> I saw the parameters DEFAULT_CACHE_SIZE about having documents in memory.
> I will check the HText_new() routine, I compile with some option (I do not
> remember now) and lynx generates a lynx.leak file, now is empty.

I made changes to the development code described as follows:

* Code to recover from memory exhaustion, sometimes.  The requests for
  dynamic memory which heuristically most often fail for lack of memory
  when rndering large documents are the calloc() calls in split_line.
  They are replaced by LY_check_calloc() which has the same calling
  conventions as calloc() but additionally checks if "enough" memory is
  available for the requested amount plus some margin and tries some
  remedial action if this is not the case.  The additional safty margins
  are required to make it likely that other allocation requests in other
  places of the program won't fail before the next check.  The actions
  which may be taken in order to avoid exiting if low memory is detected:
  (1) Try to unload cached documents (other than the one currently being
  loaded), until we seem to have enough memory.  (2) If that fails (or
  there are no other documents cached in memory), try to fake a 'Z' key
  interruption; this will have the same effect as if the user had pressed
  'Z' so it will only detected if some other part of the program tests
  HTCheckForInterrupt() and acts on it.  (3) If this seems not to be
  sufficient to stop loading, halt appending of normal text data to the
  document structure (A warning *** MEMORY EXHAUSTED *** is appended
  instead). - KW

(It is currently enabled in the devel code for everything but VMS.)

I tested this a bit with artificially restricting memory use on
solaris (with bash's ulimit -d).  It isn't guaranteed to work, and
probably has a better chance of succeeding if the available memory
isn't too low.  If there is a better way to test for remaining available
memory than attempting a malloc(), then it should be used instead.

You may get (more or less) only the relevant changes by retrieving the
diff between

    2.7.1ac-0.79
and
    2.7.1ac-0.80

from <URL:http://sol.slcc.edu/cgi-bin/lynx/patch>.  You should be able to
make the equivalent changes to the 2.7.1 release code if you can't or
won't port the development code to Minix.  (You probably would
have to make some of the changes manually, I doubt that applying
the diffs with "patch" will work well.)


If this turns out to work well (for the devel code, any OS), one can set
-cache=NUMBER (or equivalent lynx.cfg option) to something much higher
than the default 10 and limit memory use externally, rather than using a
low number of cached documents to somewhat limit memory use.

That is, other lynx-dev readers are encouraged to test it. :)

     Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]