Re: [Chicken-users] Problem with threads

[Felix]

From: Jeronimo Pellegrini <address@hidden>
Subject: [Chicken-users] Problem with threads
Date: Fri, 19 Nov 2010 15:10:28 -0200

> 
> (use srfi-18)
> 
> (define looping-thread
>   (let ((loop (lambda () (do ((i 0 (add1 i)))
>                         (#f)
>                       (print ':: i)))))
>     (thread-start! (make-thread loop))))
> 
> This does not start the thread on my system (Linux/AMD64), not
> even after several seconds, until I did (thread-join! looping-thread).
> 
> It also seems to run when I change its quantum:
> 
> (thread-quantum-set! looping-thread 10)
> 
> But it seems to run for a while only, and then sleeps undefinetly
> again.

If you do thread-join!, does it also sleep with this quantum set?

> 
> I udnerstand that Chicken implements SRFI-18 and not SRFI-21,
> but isn't there any way to force the scheduler to actually make
> one thread start working without pausing indefinetly like that,
> other than using thread-join!?

You say that as if the behaviour you describe was intended by the
implementation.

> 
> I'm asking becuase I have a didactic implementation of thread pools,
> but after creating N threads in a pool, I can't
> call thread-join! (because al those threads loop forever, and
> I'd like to send tasks from the REPL -- and the REPL would not be 
> available anymore if I issued thread-join! there).
> 

I can not reproduce this from the REPL. If I remove
the print call and load the code into csi, have 100% cpu
usage and can enter expressions into the REPL. If I replace
the print call with code to increment the variable, I can
print its contents and they are constantly growing.

Have you used that example in compiled code? Does it only
happen in the REPL? Can you show me a transcript of what
the exact steps you do execute your test program?

> 
> Also, I believe I've found a little bug. When I force a deadlock:
> 
> (define a (make-mutex))
> (mutex-lock! a)
> (mutex-lock! a)
> 
> I get this error:
> 
> Error: bad argument count - received 1 but expected 0: #<procedure 
> (##sys#halt)>
> 
>     Call history:
> 
>     <syntax>      (mutex-lock! a)
>     <eval>    (mutex-lock! a)   <--
> 
> Looks like this is because scheduler.scm uses (##sys#halt "deadlock")
> at line 166, but ##sys#halt has zero arity (if I understand correctly it's
> defined in line 216 of library.scm).

Yes, indeed. Thanks very much.


cheers,
felix