From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@math.gatech.edu
Subject: Re: PATCH: wrappers, unloading, and dependencies
Date: Thu, 17 Dec 1998 09:05:30 +0100 (MET) [thread overview]
Message-ID: <199812170805.JAA05667@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Wed, 16 Dec 1998 08:46:39 -0800
Bart Schaefer wrote:
>
> On Dec 16, 11:39am, Sven Wischnowsky wrote:
> } Subject: PATCH: wrappers, unloading, and dependencies
> }
> } With the patch I send modules on which modules whose unloading is
> } currently delayed [depend] may be unloaded immediatly. This means
> } that if the wrapper function uses data or functions of the module
> } depended upon may fail if the access appears after the execution of
> } the shell function and the lower level module was unloaded (and could
> } be unloaded immediately).
>
> As I said before, I think you're going to end up delaying unloading of
> all modules until all wrappers are finished. Now that you've split the
> boot_/setup_ and cleanup_/finish_ parts, there's no reason to unload a
> module instantly, so why even try?
>
> Following the dependency chains around is much more complicated than
> necessary, I think.
Yes, using one static variable in module.c to count all wrappers and
unloading all modules with MOD_UNLOAD when it reaches zero would be
simpler, but only if we don't care about the order the finish
functions are called. If we want them to be called from depending to
base modules we would end up with a loop like the one we have now in
unload_module().
Alternatively we could keep a list of modules in the order their
unloading was requested, but then we would need the code to keep this
list up-to-date.
>
> } But of course that wouldn't be fully secure either, we would also have
> } to enforce that modules initialize/finalize all data other modules
> } might be interested in in the setup and finish functions, *not* in the
> } boot/cleanup functions. And that, of course, can't be guarenteed since
> } module writers are free to do what they want.
> }
> } Making the implementation of setup/finish mandatory might help here
> } but doesn't ensure the right behavior either.
>
> There's no way to prevent people from writing buggy modules, period. You
> tell them the rules and they get to fix the module if it does something
> bad.
Thanks, that's what I wanted to hear. (And I will send a cleanup patch
for the module stuff today that will change the documentation.)
>
> } So we can either make find_module() be accessible from modules and add
> } a comment in the documentation the this can be used in the wrapper to
> } test if the modules needed are still loaded or we use the patch below
> } to delay unloading of modules depended upon and to change the
> } documentation.
>
> If find_module() were accessible from modules, then a module could auto-
> load any others on which it depends; that'd be pretty nice. But I would
> not require modules to test again when unloading, as that's something the
> shell should be able to make work.
Making it accessible is simple, maybe with a little wrapper so that we
return the module itself (not the node).
>
> Now, should I apply this patch, or wait for some other one?
Refering to my comment above, I'd say yes.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1998-12-17 8:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-12-17 8:05 Sven Wischnowsky [this message]
-- strict thread matches above, loose matches on Subject: below --
1998-12-16 10:39 Sven Wischnowsky
1998-12-16 16:46 ` Bart Schaefer
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=199812170805.JAA05667@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@math.gatech.edu \
/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).