Re: Last patch

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Dec 4, 10:06am, Sven Wischnowsky wrote:
} 
} I wrote:
} 
} > I'll have a look at the weekend. Let's see if we can do it with
} > signal-queueing.
} 
} I had.  It's a nightmare.  I haven't yet checked everything, but the
} patch already has ~3600 lines.
[...]
} Some (if not most) of the things I haven't tried to make secure yet
} include the history code and the job- and signal-tables. But even
} without them, the many queue/unqueue pairs don't look like the right
} solution.  Maybe we should try to identify a hopefully small set of
} places where we put them, each making a possibly large part of the
} shell secure and later try to move the pairs further and further down
} the call chains.

Yes, that would be my suggestion, with some careful choosing of the large
parts.  (I'm sorry that I don't have time right now to do much more than
offer advice about this -- I'm the busiest with work right now that I've
been for some months.)

Another thing is that we should recognize that zsh has been working
reasonably well without this for a very long time.  If we can pick off
the places where the shell spends most of its CPU cycles, we can make
what problems there are, far less likely.  Then worry about covering
the rest of the cases as we have opportunity.

} The main problem seems to be that we
} have many places where we get, for example, a pointer to a hash node,
} keep it in a local variable and later use it.
[...]
} In many places this can quite easily be wrapped inside a queue_signals()/
} unqueue_signals() pair but there are places where it is extremly
} difficult (execcmd(), for example, or the function-autoloading code).

At least the two examples you gave are cases where I think it would be
OK to queue signals over a wider span of code.  Some signals are blocked
for a good portion of execcmd() already, aren't they?  (To avoid SIGCHLD
races.)

} Another problem is the module code.  Most of this could probably be
} solved by queue/unqueue pairs (I've done/tried that) and by
} disallowing to unload modules from a handler.

Couldn't attempting unload from a handler be treated the same as from
a wrapper, i.e., just set the MOD_UNLOAD flag on the module struct?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net