Am 03.07.2014 17:34, schrieb Daniel Leslie:
Unless I missed a radical change in Chicken, its SRFI-18 threads are
green threads and not real system threads. As a result, blocking
operations will block all threads and no real gain is had from the
hardware's support for multithreading.
That is strange, I've experienced alex's problem too - having to yield a
little to give the REPL some room.
Anyhow, for others who might come across this thread: alex's idea works
great, but you need to be careful with blocking IO on your REPL. If you
don't use parley
Unless I missed a radical change in Chicken, its SRFI-18 threads are green
threads and not real system threads. As a result, blocking operations will
block all threads and no real gain is had from the hardware's support for
multithreading.
Because of those issues I suggest avoiding SRFI-18
Hello, I wanted to do some live game programming with Chicken Scheme. I
would like to adjust my game whilst it is running a game loop. I tried
srfi-18 threads for this but found it to be too unwieldy. So I wondered
if there is a way to process the repl inside the loop. An example of
what I
Hi Pluizer,
I've tried to make a poll-based repl like you're talking about for the same
purpose. Have a look here and see if that helps:
https://github.com/Adellica/prepl
K.
On Wed, Jul 2, 2014 at 12:40 PM, Richard plui...@freeshell.de wrote:
Hello, I wanted to do some live game programming
Thanks Kristian and Daniel,
Both options seem to be the thing I was looking for. I'll test them both
and see what I like best.
thanks,
Richard
On 07/02/14 17:43, Kristian Lein-Mathisen wrote:
Hi Pluizer,
I've tried to make a poll-based repl like you're talking about for the
same purpose.
I have something like this set up on Unix. I start a separate SRFI-18
thread with a procedure that starts the main loop. Then (in the original
thread) I call repl. The main loop calls thread-yield! after every
iteration to make sure that the original thread evaluates each
expression as soon as
alex scripsit:
I had some trouble with this last part at first: the original thread
waited several seconds before evaluating my input. I think that the
fix was nothing more than calling thread-yield! every loop
iteration.
If you are depending on thread-yield! for correctness rather than
