From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20904 invoked from network); 16 Dec 1998 16:50:33 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 16 Dec 1998 16:50:33 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id LAA13590; Wed, 16 Dec 1998 11:47:44 -0500 (EST) Resent-Date: Wed, 16 Dec 1998 11:47:44 -0500 (EST) From: "Bart Schaefer" Message-Id: <981216084639.ZM12905@candle.brasslantern.com> Date: Wed, 16 Dec 1998 08:46:39 -0800 In-Reply-To: <199812161039.LAA01405@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "PATCH: wrappers, unloading, and dependencies" (Dec 16, 11:39am) References: <199812161039.LAA01405@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@math.gatech.edu Subject: Re: PATCH: wrappers, unloading, and dependencies MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"eUbI62.0.HK3.mG-Ts"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4825 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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. } 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. } 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. (This time I didn't send you an extra copy, Sven.) Now, should I apply this patch, or wait for some other one? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com