From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id KAA15473 for ; Tue, 25 Jun 1996 10:10:25 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id UAA13504; Mon, 24 Jun 1996 20:00:59 -0400 (EDT) Resent-Date: Mon, 24 Jun 1996 20:00:59 -0400 (EDT) From: Zoltan Hidvegi Message-Id: <199606250001.CAA06897@bolyai.cs.elte.hu> Subject: Re: BUG: useheap in doexpandhist() To: schaefer@z-code.ncd.com Date: Tue, 25 Jun 1996 02:01:00 +0200 (MET DST) Cc: zsh-workers@math.gatech.edu In-Reply-To: <960624142056.ZM2050@zyrcon.z-code.com> from "Barton E. Schaefer" at "Jun 24, 96 02:20:54 pm" Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368 X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hj01p1.0.wI3.wmopn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1441 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > } Unfortunately there are some zsh functions which are not reentrant which > } cause problems when a signal comes. > > In the case I suspect, though, all zsh should have been doing when the > signal arrived was sitting idle at the PS1 prompt. The signal is not > arriving during the completion, as far as I can tell; rather, the heap > allocation has already been left in a confused state, and trying the > completion just happens to be what makes zsh notice the bad state. > > Is that what your patch was intended to fix? Yes. The signal trap can leave the allocation in some undefined state. My patch just makes sure that after executiong the trap the original allocation state is restored. > Yes, the right thing to do is to eliminate the global pointers to alloc > functions, and call the desired ones directly. The pointers were used > in the first place so some utility routines (like dupstring) could be > written once and then be used regardless of whether heap or permanent > allocation was desired. The zsh heap, in turn, is just a crude garbage > collection mechanism, as I'm sure you're aware. > > Unfortunately, at this point there are probably so many routines that > depend on having this memory management magically handled for them, that > it'd be as big a change to fix that as to make everything reentrant. I think that the heap used in zsh is very useful. It is convinient, it certainly guarantees that there is no memory leak if the heap is used and it is efficient since instead of calling malloc()/free() frequently we call these only a few times. This can make things faster since malloc()/free() can be very expensive if sbrk()/brk() is called. Once I played with the Linux ypserv and I found that it spends most of its time in sbrk/brk in some situations. Then I linked it with the malloc from zsh with the brk staff removed and it become much faster than before. Zoltan