Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2003:
[Freeciv-Dev] Re: list cleaning
Home

[Freeciv-Dev] Re: list cleaning

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <per@xxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: list cleaning
From: Raimar Falke <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Sat, 29 Nov 2003 16:04:10 +0100

On Sat, Nov 29, 2003 at 02:38:18PM +0000, Per I. Mathisen wrote:
> No, I'm not talking about this list ;)
> 
> Recently I rewrote genlist.c to do lazy deletes. Instead of removing nodes
> in the linked list when they are 'deleted', they are just marked as
> deleted and ignored from then on until a call to the list's prune()
> function is done. When prune() is called, the deleted nodes are actually
> deleted. This makes the lists safe to nest iterations deeply while
> deleting nodes at will - currently such safety is kludged with
> unit_list_iterate_safe(), which is uglier, slower (malloc for each use)
> and less safe unless done everywhere.
> 
> This worked fine in the server, since the number of lists is limited and
> easily pruned in one key place. It is harder to do in a clean way for the
> client, so some other maintainers want to 'normalize' iterators (no return
> or goto inside iterators allowed) and count depth of iterator nesting, and
> then when we're all the way out, we prune the list automatically.

There is another way. If this 'normalize' iterators are in place we
can ensure with assert that unlink isn't called when we are currently
iterating over the list. Such cases would then be replaced (by hand)
with safe iterations. This is the conservative approach: you can be
sure that there are no unsafe unlinks and there is a known and
constant memory and cpu-time usage.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Python is executable pseudocode. Perl is executable line noise"
    -- Bruce Eckel


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