zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: zsh 5.0.6 hanged in freejob from TRAPCHLD
Date: Wed, 01 Oct 2014 09:04:21 -0700	[thread overview]
Message-ID: <141001090421.ZM5838@torch.brasslantern.com> (raw)
In-Reply-To: <20141001164002.0f9b1e01@pwslap01u.europe.root.pri>

On Oct 1,  4:40pm, Peter Stephenson wrote:
} Subject: Re: zsh 5.0.6 hanged in freejob from TRAPCHLD
}
} On Wed, 01 Oct 2014 17:25:33 +0200
} Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
} > 
} > Eww. Wouldn't it perhaps be easier and better in the long run to replace
} > this whole save/restore/globals concept with non-global structs and make
} > all the lexer functions take a pointer to the relevant instance of the
} > struct.
} 
} You'll soon find the paths you need to pass the structures through
} proliferate somewhat hair-raisingly.  That may lead to useful
} simplifications, though, so this isn't an argument against doing it.

It's not even quite that simple, some of the fields require their own
memory management.  Moving it onto the call stack and passing it around
that way would only change the lexsave/lexrestore calls into something
that allocates/cleans up a local lexstack object.  (Hey, why don't we
rewrite the whole shell in C++ instead?)

It'd be a large step in the right direction to have ONE global -- a
single (struct lexstack *) -- and have lexsave/lexrestore swap that
pointer rather than copy each of the fields.  However, doesn't remove
the need for the signal queuing (see "fields require their own
memory management").

Futher, that still means finding everything that references those
globals -- some of them are used outside the lexer to examine the
current lexer state -- and replacing all those mentions with deref
through the new global pointer.  Yeah, the compiler will sort that out
if we just remove the declarations of the globals.  Busywork.

Then you get to do that for all the other things that use batches of
globals in this way (see execsave/execrestrore, trap scopes, etc.) 


      reply	other threads:[~2014-10-01 16:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30 17:21 Vincent Lefevre
2014-09-30 23:18 ` Bart Schaefer
2014-10-01  0:53   ` PATCH signal-safe lexrestore() [Re: zsh 5.0.6 hanged in freejob from TRAPCHLD] Bart Schaefer
2014-10-01  9:00   ` zsh 5.0.6 hanged in freejob from TRAPCHLD Peter Stephenson
2014-10-01 14:53     ` Bart Schaefer
2014-10-01 15:25       ` Oliver Kiddle
2014-10-01 15:40         ` Peter Stephenson
2014-10-01 16:04           ` Bart Schaefer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=141001090421.ZM5838@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).