[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: tomas
Subject: Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless
Date: Fri, 17 Sep 2004 10:34:16 +0200
User-agent: Mutt/1.5.3i

On Fri, Sep 17, 2004 at 08:28:16AM +0200, Johannes Berg wrote:
> Tom Lord said:
> > I think that there may be a silver bullet or two for punning apps and
> > libs.  [...]

Interesting thoughts overall. I think it's becoming more and more important
as the command line is giving way (with lots of pains) to different kinds
of user interfaces.

And you can see quite a few applications chaotically trying to find a good
path. Apache. Browsers with their plugins. And so on.

> >    ~ 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.

An example: PostgreSQL has an extension mechanism for its backend. Quite
cool. It uses memory pools (it's transaction-based, which is unsurprising
for an RDBMS), quite comparable to Apache. It makes extensive use of setjmp/
longjmp, which makes it quite difficult to write extensions in languages
whose infrastructure would like to have control of the stack itself
(AFAIR it used to be a stumbling block for Guile).


> >       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.

I took it to mean `a high-level description of an interface', where we
have to acknowledge that an interface is more complex than just a bunch
of functions and data types.

-- tomás

Attachment: pgpcxJm7d5mXF.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]