Wed Aug 30 03:39:46 CEST 2006
forgot to jump on that train!
i think most of the machinery is already present in libpf/thread.c
i lost the train of thought.. why go single threaded? to fix some of
the problems with memory allocation, which is currently a bit of a mess.
probably this lock-free approach is worthwhile to look at first.
ok, the train was: to use poll/select in the core, i need to make
the parser pre-emptive. the way i wanted to do that, is to make
the core single threaded to make it cleaner, and have the parser
be a thread that converts io to synchronous binary stream.
so, a little survey on the occurence of locks in pf
- packet reference count
- atomic stack for memory allocation of list/atom structs
- symbol hash
- packet pool lock
these are for true blocking operations, so need to be preserved
- thread -> command_queue