[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless
From: |
Johannes Berg |
Subject: |
Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless |
Date: |
Fri, 17 Sep 2004 08:28:16 +0200 (CEST) |
User-agent: |
SquirrelMail/1.4.3a |
Tom Lord said:
> I think that there may be a silver bullet or two for punning apps and
> libs. I think that vu_ is a plausible choice for part of that silver
> bullet.
The vu_ layer certainly could contribute to this solution; however I do
think it is -- as is -- too heavy-weight. We'd also need to consider the
"deployment" of vu_ in existing apps/libs like libz, "libpatch", ...
For this to be really useful, a simple vu_ layer must exist that libraries
can trivially link, and which provides no functionality loss to start
with, except by providing an exported function that can be used to push a
different vu layer for use by the application.
As a side note -- your following points all seem to imply that you want
the library to basically have the same interface as the application. I
don't think that really is a useful idiom, ideally a library would provide
a much richer interface than an application, also allowing access to
partial functionality.
> Overall, it's a hard problem that I think needs to be solved with a
> bunch of strict conventions for both apps and library functions,
> ideally automatically verifiable, convering at least these issues:
> ~ as you say: stream handling. For example, what does the
> the std{in,out,err} convention mean for two app-like
> routines being connected in a pipe-like way within a single
> process?
And what if these two come from different libraries?
But I think at this point you're not going to gain much from libraries as
opposed to fork&exec.
> ~ flow control and stack handling. If I have app-like library
> routines, can I "run" two of them concurrently in one process?
> Do they share a C stack? Can they use setjmp/longjmp in a
> coordinated way?
I don't really see any need for this.
> ~ signal handling. Some apps want to use signals in special ways
> (e.g., timers, sigstop handling, etc.) How can two separately
> developed app-like library modules both do this, in a single
> process, in a coherent way?
This is possibly the hardest problem.
> ~ argument and return types. Apps take the primary parameters:
>
> char * environ[];
> char * argv[];
> int argc;
>
> and "return" an exit status. Interesting, but, in library
> routines, don't we want a more strongly typed interface?
> And what about "indirect parameters" like file contents?
>
> A SWIG-like approach might be helpful here although it is
> not easy (imo) to define an appropriate one.
Isn't SWIG trying to solve a different problem? Afaik SWIG will try to
wrap a library within a scripting language, while (as I understand it) we
are discussing a C library that exports functions.
> There is a brute-force answer that would maximize the reusability of
> existing code: some unholy mix of vu and vu-like wrappers around other
> system calls, plus Posix threads, all giving a 95% approximation of
> a separate process to a library module.
>
> Perhaps, though, by using a slightly different programmign model,
> the problems can be solved in a less brute-force way, with less
> "cognative overhead". For example, if the details of flow of control
> took a back seat to automatically computable data dependencies, the
> run-time system could do a lot in the areas of flow control and stack
> handling (at least).
>
> One problem with the brute force way is that, although it works fine
> in theory, a programmer must know an aweful lot about unix (or else
> follow a lot of otherwise inexplicable coding conventions) before they
> can correctly write even the simplest app-like library module.
[...]
I'll try to finish some more thoughts, but right now have to do some work.
johannes
- Re: [Gnu-arch-users] --forward mostly harmless, (continued)
- Re: [Gnu-arch-users] --forward mostly harmless, James Blackwell, 2004/09/14
- Re: [Gnu-arch-users] --forward mostly harmless, Tom Lord, 2004/09/14
- [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, Eric Wong, 2004/09/15
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, Andrew Suffield, 2004/09/15
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, James Blackwell, 2004/09/15
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, chth, 2004/09/15
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, Matthew Dempsky, 2004/09/15
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, chth, 2004/09/15
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, Johannes Berg, 2004/09/16
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, Tom Lord, 2004/09/16
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless,
Johannes Berg <=
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, tomas, 2004/09/17
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, Tom Lord, 2004/09/17
- Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless, Tom Lord, 2004/09/17