Hmm, I have verified that the stack is certainly part of the problem,
and since I am trying to do I/O in this thread, I can see the problem
there too. I guess I'll have to twiddle a little more then, and for
now, I guess the answer is that gforth is not pthread safe.
Not yet, at least. ;(
Thanks!
DaR
On May 3, 2004, at 8:25 AM, Bernd Paysan wrote:
On Monday 03 May 2004 16:57, Dennis Ruffer wrote:
I've now tried to do a simple POSIX thread experiment, and I wonder if
anyone can explain why it always causes gforth to crash. I've
included
the source and the crash below. If the comment in readThread is
removed, output is produced but it crashes quickly. With the comment,
it does not crash until you hit a key. I've tried various
combinations, but haven't found anything that appears to work. Am I
doing something wrong, or is gforth simply not pthread safe?
First of all, POSIX threads mean that all memory is shared between the
two
threads, including the Forth stacks. If you create a new thread in
Gforth,
you must at least give it a new stack, too. And to make Gforth
thread-save,
some of the global C variables must be thread-local, too (especially
those
used in the C call and callback interface).
Callbacks do not create a new Forth stack, they just use the stack on
top of
what has been used by the caller. For threads, that's the wrong
approach.
I'd suggest to write another callback interface primitive (and
corresponding C word) which creates a new set of stacks when called,
and
frees those when the callback returns. This should be helpful for those
callbacks that can be called from other stacks.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
