Sat Nov 11 12:01:01 EST 2006
so, i have a dilemma. i waited for a couple of days to think, but i'm
still not sure. i went to a lot of trouble to make pf thread-free, but
do i want to change things that are unfrendly to threads in general?
let's see.. now, in the code there are several locks. should i take
them out? the packet allocation code could be cleaned up a whole lot,
and unified with stream stuff and general purpose object ordiented
everything should become simpler when the locks are removed. i'm
convinced i don't need threads, so there's really no reason to keep
the locked code around. alright, i'm tagging the code now, and will
put a forked archive on ataraxia.
ok, here we go. the first thing i run into is the reuse mechanism: i
should make lists and atoms use the same reuse mechanism as other
packets : tied to symbols.
so, what is data in pf? it is either owned by a VM, or it is owned by
a re-use list tied to a symbol. So the root of the data tree is the
symbol hash together with a list of all VMs. Symbols are 'global' in
the C sense. They are properties of a process, not a VM.
Atoms and lists are owned by the 'symbol' and 'list' symbols.
- all locks removed
- toplevel data tree = symbol hash + VMs
- symbols never get freed
- other things never get freed unless it's asked for explicitly
- fast allocator removed, use reuse stack
- list/atom reuse mechanism unified with packet reuse mechanism (symbol.c)
- unify packet id with it's pointer in memory pf_packet_header() -> identity()
- a packet is something with a reference count
- join all global variables in one struct for cache opti
- atom/list reuse and packet reuse are not the same due to refcounts
- strings are just wrappers for malloc : they are not really deterministic
check if this is a problems
probably best to do make packet ID == packet pointer at this moment,
since it would clean up a lot of cruft. going to make a safety commit
probably i need to keep two toplevel free lists for lists and atoms,
to not interfere with them being used to store packets. too lazy and
hungry atm to figure out if it's possible to do without. maybe i
should save all global variables that are accessed a lot close to each
other for cache opti?
got it to compile, however there's something wrong with the packet
management: fixed, refcount problem.
retired strings have their buffers stripped. what this means is:
strings are really just a wrapper around malloc, meaning, they are not
really reusing their data. so if you want predictable performance, you
cannot use strings. there's really no way around this, since hreusing
the buffers could lead to huge memory inefficiencies.
looks like it's working now..
PF is officially tread-free :)