[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: chth
Subject: Re: [Gnu-arch-users] libpatch hack WAS: --forward mostly harmless
Date: Wed, 15 Sep 2004 21:08:29 +0200

> I took a stab at integrating patch into tla the other night.  It was a
> fairly quick hack on my part, and probably not optimal.  I chased down
> some fd leakage, and removed some large text sections (help/usage) in
> an attempt to save some space.
> Since the performance I was looking for is fairly disappointing at
> initial use, I don't plan on continuing this myself.  Maybe users of
> operating systems with a less-efficient fork() could try this out and
> improve upon it.  I don't think I'll be gaining anything from it, and
> attempting to maintain patch would be too much for me.

Hi Eric, Paul

Thats fairly obvious, considering that patch does a lot I/O and even
some processing and its only forked a few times.

Further integrating patch into tla might shove a maintainace obligation
to the tla programmers. This is prolly a bad idea.

But nevermind librifying patch has it's benefits. Just convince the
patch maintainer (hence the cc: to Paul) to accept it in the main patch
distribution then other tools like tla (or the patch command itself)
could link to libpatch then.

In my opinion is that almost any application should be a library and the
commandline frontend should be just a generic driver like (schematic

int main (int argc, char *argv[], char *envp[])
        int (*libmain)(int, char**, char**);
        /* every /bin/foo has an associated */
        void* libhandle = dlopen("lib"+basename(argv[0]));
        /* defines an int libfoomain(int, char**, char**); */
        libmain = dlsym(libhandle,"lib"+basename(argv[0])+"main");
        return libmain(argc, argv, envp);

Well, long way to make such happen.


reply via email to

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