chicken-users
[Top][All Lists]
Advanced

[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".




reply via email to

[Prev in Thread] Current Thread [Next in Thread]