[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Problem with threads
From: |
F. Wittenberger |
Subject: |
Re: [Chicken-users] Problem with threads |
Date: |
Sun, 21 Nov 2010 23:37:30 +0100 |
or with "print"?
Am Samstag, den 20.11.2010, 16:12 +0100 schrieb 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).
Please just try to add
(flush-output (current-output-port))
right after your (print...)
((((((it might even help to end the print with a newline, but i never
wrote that))..)
If your thread is still "not doing anything", than it's a thread issue,
otherwise normal output buffering. (Which might have changed recently.)
> > 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).
Jeronimo, iff - we better lay that off to private mail for a while. It
can become confusing. There are known issues.
> I can not reproduce this from the REPL. If I remove
> the print call and load the code into csi, have 100% cpu
see above - kinda confirms the "buffer effects" hypothesis to me.
wait...thinking again. the following is all a wild guess without any
attempt to check in sources: could it be that a flush-output has been
dropped recently? Maybe wrt. to "buffer full" conditions? Or maybe
just modified slightly? Everyday's off-by-one could be just enough.
> > at line 166, but ##sys#halt has zero arity (if I understand correctly it's
> > defined in line 216 of library.scm).
right in the middle of "known issues".