Re: Understanding ACI

From: Jörgen Sigvardsson <jorgen.sigvardsson@kau.se>
Subject: Re: Understanding ACI
Date: Tue, 20 Feb 2001 10:11:16 +0100

Next Article (by Subject): Re: Understanding ACI Peter Busser
Previous Article (by Subject): Re: Understanding ACI Amon Ott
Top of Thread: Understanding ACI Jörgen Sigvardsson
Next in Thread: Re: Understanding ACI Peter Busser
Articles sorted by: [Date] [Author] [Subject]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 20 February 2001 09:23, you wrote:
> I already got some negative experience with these lists when I tried to
> extract some useful info from one of them (without success). There are
> several reasons why I decided not to use them:
>
> - I could not find any useful documentation
That's Linux allright. 
> - The lists are typeless - now I get compiler type checks, which tell me if
> I got something wrong (in fact, the data storage is a nasty hack)
> - Memory allocation without being sure about the size of the type is very
> dangerous
This could be solved quite efficiently given that all elements have the same 
size (i.e. same type) by using a element size field in the list head. All 
that is required is a proper initialization of the list. list.item_size = 
sizeof(list_item_t)

> - They would not save much code - the list handling itself is rather easy
True, the code is easy. But I have seen bugs propagate through a project like 
a forrest fire in august. The thing is that when humans do easy things, they 
tend to just repeat what they did earlier without paying no attention to what 
they are doing. There was a bug in a list insert function in a 40k line 
application which I was developing at [CENSORED]. Of course, that code was 
easy, therefore it was just repeated all over the application. The repeat 
method was copy'n'paste. It sort of sucked when I had to clean up the mess.
I'm not generalising all humans, but a large portion of them. 

> - My lists have a significant speedup for repeated lookups via the curr
> pointer 
Can be solved, if not using the Linux list.

> - Spinlocks are directly associated with my lists.
True. But this can be incorporated into the list design.

> - Most of my lists have to be persistent, so I need individual code for
> saving the data only anyway
True. But you can always register callbacks for a list to handle custom 
persistance features.

I guess the Linux list implementation just blows. Period. :) It was probably 
nothing but a hack, by a hacker for hackers. One bad thing about a g

> But we can discuss these things, if you like...
Since my arguing techniques are somewhat lacking, I think I'll do an 
implementation for my modules and then I'll show it to you - with acompanying 
docs! 

- -- 
Jörgen Sigvardsson, B. Sc.
Lecturer, Computer Science Dept. Karlstad University
Tel: +46-(0)54-700 1786
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6kjS0JtcD8rikkmwRAqHsAJ9CSAY8cfbAbojmPTPqmX/M6th77ACgkQUZ
wSYjsrTJM1Uei0yUWndMjd0=
=f4qt
-----END PGP SIGNATURE-----
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.