[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Problem with threads
From: |
Felix |
Subject: |
Re: [Chicken-users] Problem with threads |
Date: |
Sat, 20 Nov 2010 16:12:07 +0100 (CET) |
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