[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: akka/38: Akka autotools fixes (security, speed, beauty)
- To: developer at arabeyes dot org
- Subject: Re: akka/38: Akka autotools fixes (security, speed, beauty)
- From: Mohammed Elzubeir <elzubeir at arabeyes dot org>
- Date: Mon, 10 Jun 2002 09:28:32 -0500
- User-agent: Mutt/1.3.28i
On Mon, Jun 10, 2002 at 01:24:09PM +0200, Chahine M. Hamila wrote:
> Salaam Samy,
> (I'm CCing Moe so he can maintain the bug tracking system with whatever he
> thinks is suitable:))
And I'm moving this discussion to the 'developer' list.
> Phactorial - a *crit :
> > The UNIX world has to be a reliable world. It is better to give that option
> > of retrying that pthread as systems with high loads might have that problem.
> > If you have any problems with the changes, I am always to happy to change
> > them.
> Samy, if there's an error, and you want to avoid load driven errors then do
> something that will detect high loads and respond accordingly. Retrying without
> checking for the exact reason the first failure occured is a bad thing, it will
> at best fail again. At worst, it will work, and we're likely to have some leak
> somewhere or some buffer overflow... When it comes to software behavior, things
> must be square, ot we're likely to be facing a serious bug.
> > The ioctl commenting is all what really needs commenting (other than
> > algorithms, which are actually not too difficult to understand). Some
> > potential porters might not be well versed in Linux's system architecture,
> > or FreeBSD's, etc... It is better to do this, and it doesn't waste too much
> > time :D
> You're most welcome to do that if you've got motivation for it.
> > You have the Microsoft term of software:
> > - If it works for me, it works for everybodys
> > - It must work (not the best way)
> It must work, sure, but make it work the right way, no approximative way.
> > - We must do everything the easy way
> > My terms:
> > - It must be efficient and stable, I have completely removed glib
> > dependency (it is only left as a fribidi dependency now, which is
> > better, as it reduces our future work of removing this dependency
> > when prior versions of fribidi die out)
> ok, that's fine with me.
> > - You don't what fuzz, use what you need. Using more libraries makes
> > your program much less portable, much less efficient (not as quick,
> > we don't want yet another layer on top of system call execution)
> Using more libs do not reduce the portability unless you're using an obscure
> non portable lib. It certainly does not add a layer in any case, unless your
> soft needs another layer, but very much the opposite. A library is a collection
> of pieces of code that you would otherwise write in your software, but I'm not
> teaching you anything here, am I. The only cost is at load time, and that's
> unsignificant. The alternative is to replicate code on the system, and that
> costs time and space.
I tend to agree with Samy here. I'm all for reducing library dependencies.. as it
is, Akka has far too many dependencies for what it does. That's just my take on
it. I would be very much in favor of a 'light-weight' akka.
> > - Source code must be readily reabable by the programmer, no need for
> > doc++, if you wish, I can return to that ugly mung :)
> Yes, please leave doc++, not everyone is as good as you are reading code, so
> newbies might find it useful to have a documentation besides the code. As I
> said before, ugly is really in the eyes of the beholder, I personally find the
> doc++ style quite breathable compared to the asphyxiated ANSI style, but it's
> really not for aesthetic reasons that I think doc++ style comments should be
The 'programmer' also reads the doc++ output. Thought I would note that the
commenting is incomplete and inconsistent still. I would suggest adding the
comments, but maintainng the doc++ style (which I personally like) - it's very
readable when viewing src, and very nice to output documentation later.
> > - I only stuck with light ANSI things, if it involved putting back
> > the features we use, then I wouldn't have implemented these things
> > - In that system() call, I replaced perror because system does NOT
> > set errno. System is simply a wrapper to execve, the only time it
> > would errno if /bin/sh (or whatever the configured shell is) is non-
> > existant or has other problems (permissions, etc...).
> True, but that's precisely the kind of problems you encounter most of the time.
> At least, these are the ones I needed when testing Akka. If you really feel
> strong about that, you can put both, it doesn't cost anything, and it'll
> probably be better, coz I still think it's important to leave the current
Agree with Chahine here.
> > We wouldn't
> > know the return value of loadkeys this way. How about I replace
> > system with a fork();execve() and check the return value of the
> > child instead? I'll make it print the value in LOADKEYS instead.
> > Do you want me to write a configuration wrapper (to autodetect the
> > configuration files, the default configuration file is not very
> > portable at all)?
> Yes, that seems fine.
> > - I did not touch that in the main loop, as it was off the autotools
> > cvs. Maybe you should check that? Someone could've have screwed
> > with it...
> I was reading it from the patch you provided. It's during the printing of an
> error message, where /dev/tty%d used to send ttyn instead of consolen. In any
> case, we agree so no need to discuss it for years:)
> > - pthread, hrm, you must have error checking here, otherwise, we will
> > be interfacing with an unexistant thread
> > - I checked the inline, it is valid
> > - Please refrain from sharing signals too much. That is probably the
> > reason for that console corruption you were talking about. I will
> > be adding a wrapper on top of terminate sig that filters/resets all
> > signal handlers before jumping to terminate_sig itself.
> Yes, that's one of the things on the todo as put in the code. It would be a
> very good thing if you clean that indeed.
| Mohammed Elzubeir | Visit us at: |
| | http://www.arabeyes.org/ |
| Arabeyes Project | Homepage: |
| Unix the 'right' way | http://fakkir.net/~elzubeir/|