From: "Bruce Ellis" <bruce.ellis@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] dynamic module loading and versioning
Date: Wed, 19 Apr 2006 19:37:20 +1000 [thread overview]
Message-ID: <775b8d190604190237o286e38cfjd281aa818ea8e0@mail.gmail.com> (raw)
In-Reply-To: <CB2DA36D-DA67-4958-8658-6AE3E645FBEE@cibernet.com>
inferno is a bit more clever. only the used functions from a load
of Sys are required. everything is a module, tho many modules
are apps that can be run from whatever shell. the code, if it be
jitted or not, is shared. the module data is copied. i like it.
strong type checking rules.
and it achieves the goal of making apps tiny.
brucee
On 4/19/06, Michael Baldwin <michael@cibernet.com> wrote:
> > the boundary is a bit blurred on inferno, because the explicitly
> > module loading there is most commonly used to load what on other
> > systems would be libraries. but the result, at least as
> > implemented, has a very different feel from the shared library hell
> > on unix and windows.
>
> Aren't some of the same maintenance and versioning headaches
> associated with shared libraries still there with dynamic loading of
> modules? In Inferno, occasionally the Sys module changes (just to
> pick a nasty one), and that can wreak similar havoc as incompatible
> shared libraries unless you have a flag day. I've pondered playing
> with the PATH string in a module header to make this less burdensome,
> but I haven't seen anyone actually do it or even talk to the issue
> (OK, there aren't that (m)any users of Inferno to have people to ask,
> I know).
>
> It just seems that, if for some reason I go and change a function
> signature in the String module, say, isn't it a similar headache as
> shared libraries to keep all the programs that use the old and new
> module running and happy at the same time? I know merely adding
> functions is still compatible, but sometimes incompatible changes
> must be made (int->big for file sizes and offsets comes to mind).
> And to keep old and new programs not just running but compiling is a
> bit of a bitch. Has anyone thought about or addressed these issues
> in Inferno or another dynamic-loading system? Any lessons that can
> be learned and brought back to the unwashed world of shared libraries?
>
>
next prev parent reply other threads:[~2006-04-19 9:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-19 2:35 [9fans] Install from CD fails erik quanstrom
2006-04-19 3:53 ` Russ Cox
2006-04-19 4:25 ` [9fans] dynamic module loading and versioning Michael Baldwin
2006-04-19 9:37 ` Bruce Ellis [this message]
2006-04-19 9:40 ` Lyndon Nerenberg
2006-04-19 9:54 ` Bruce Ellis
2006-04-19 14:12 ` Artem Letko
2006-04-19 17:49 ` Bruce Ellis
2006-04-19 19:34 ` [9fans] Install from CD fails Roman Shaposhnick
2006-04-19 19:42 ` Bruce Ellis
2006-04-20 1:07 ` Roman Shaposhnick
2006-04-20 2:02 ` Jack Johnson
2006-04-19 19:45 ` Charles Forsyth
2006-04-19 21:16 ` Brantley Coile
2006-04-19 21:46 ` quanstro
2006-04-20 1:03 ` rog
2006-04-20 6:08 ` Charles Forsyth
2006-04-20 15:59 ` rog
2006-04-20 4:02 ` Roman Shaposhnick
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=775b8d190604190237o286e38cfjd281aa818ea8e0@mail.gmail.com \
--to=bruce.ellis@gmail.com \
--cc=9fans@cse.psu.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.
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).