[<<][packetforth][>>][..]
Sat Nov 4 17:43:56 EST 2006

thread changes

ok, so the central reason is of course: i can't make the VM
multithreaded using posix threads. my core data structures are not
intended for that use. there is essentially no way back, because i use
raw access everywhere.

using threads anyway complicates matters since it requires C code to
export functionality that deals with the locking/atomicity problems
outside of PF. switching the entire design to non-blocking IO makes it
possible to use cooperative PF threads to do essentially the same
thing, using more forth code instead of tedious special purpose C.

that's one. two is, that if i ban pthreads completely, i gain access
to more platforms, and a possibility to run it standalone, or under
simple operating systems: select,read,write and malloc are not so
incredibly hard to implement. i don't really need pthreads, so the
whole system becomes simpler to use and easier to interface with other
components.

- i only use it because it's there and because some libraries like
  readline do not provide non-blocking IO. threads can be convenient,
  but atomicity problems in my current implementation make it very
  awkward to used.

- the blocking parser is gone, and i use buffered output: these were
  the main reasons to use threads.

- other blocking operations can now be easily coded in forth without
  awkward atomicity issues: i can then essentially get the same
  convenience of using OS threads.


in the thread-less version, all memory allocation and reuse (atoms,
packets, ...) can be cleaned up. this is a biggy, but should make code
a lot simpler.



[Reply][About]
[<<][packetforth][>>][..]