A lot of what you said makes sense. My main goal is to replace CPS in an asynchronous application (without littering my code with cl-cont macros). So select() and poll() are what I'm using already, but transfer of control from one operation to the next around a non-blocking operation has to take place via a callback. One could build "coroutines" around real OS threads as you've laid out, but I'm guessing there would be a significant performance penalty associated (memory/context switching/etc). From my understanding, having a bunch of coroutines laying around is a lot cheaper than the same amount of OS threads in both memory and switch time. However, my understanding might be flawed...I really don't know what it would take to implement coroutines in lisp, so maybe there wouldn't be a significant amount of difference between that and using OS threads.<div>
<br></div><div>Also, I'd like to echo as well that I don't really want "green threads" where the lisp is scheduling things for me, I'd much rather have explicit control.<br><div><br><div class="gmail_quote">
On Mon, Nov 12, 2012 at 10:57 PM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've heard some people express interest before; I'd say that the interest<br>
seemed to be low-to-moderate, but non-zero.  When it's come up, I think that<br>
my first reaction to hearing someone say "I want cooperative threads" is to<br>
say "no, you don't", but I may be failing to consider all aspects of the issue.<br>
<br>
One approach to layering cooperative threads on top of native threads is to<br>
use some kind of object very much like a lock; a cooperative thread is just<br>
a (native) thread that waits for that lock before doing anything, and yelding<br>
to another (unspecified) coooperative thread basically involves releasing that<br>
lock and then waiting to obtain it again.<br>
<br>
<br>
? (defvar *the-cooperative-thread-lock* (make-lock))<br>
*THE-COOPERATIVE-THREAD-LOCK*<br>
? (defun yin () (loop (with-lock-grabbed (*the-cooperative-thread-lock*<u></u>) (print "Yin!")) (sleep 1)))<br>
YIN<br>
? (defun yang () (loop (with-lock-grabbed (*the-cooperative-thread-lock*<u></u>) (print "Yang!")) (sleep 1)))<br>
YANG<br>
? (progn (process-run-function "yin" #'yin) (process-run-function "yang" #'yang))<br>
<br>
<br>
Yow.  Are we COROUTINING yet ?<br>
<br>
That's a bit of a rhetorical question: the old stack-groups API that Scott<br>
referred to is a little richer than that and provides a clean way of transferring<br>
values between threads; that's left as an exercise.  I wrote that in terms of<br>
WITH-LOCK-GRABBED and we might actually want to use GRAB-LOCK and RELEASE-LOCK<br>
directly, so:<br>
<br>
<br>
(defun yield-to-any-cooperative-<u></u>thread ()<br>
 (release-lock *the-cooperative-thread-lock*)<br>
 (grab-lock *the-cooperative-thread-lock*)<u></u>)<br>
<br>
That's almost suspiciously simple, but it's almost exactly what Apple did to<br>
implement traditional cooperative threads in Carbon; there are some classic<br>
problems for which coroutines provide a natural solution, and the mechanism<br>
above (augmented with some means of transferring values around) is probably<br>
adequate to address many such problems (Google for "samefringe problem" if<br>
you're looking for an example.)<br>
<br>
If we have problems for which we need more than two cooperative threads,<br>
then we may need to say "yield to some specific other cooperative thread",<br>
and that would be something like:<br>
<br>
(defun yield-to-specific-cooperative-<u></u>thread (other-guy)<br>
 (release-lock-and-transfer-<u></u>ownership-to *the-cooperative-thread-lock* other-guy)<br>
 (grab-lock *the-cooperative-thread-lock*)<u></u>)<br>
<br>
and the functionality that I'm calling RELEASE-LOCK-AND-TRANSFER-<u></u>OWNERSHIP-TO<br>
doesn't exist in CCL and is a bit hard to implement reliably.  (CCL locks<br>
generally don't keep track of which threads are waiting for them and a thread<br>
that's waiting for a lock can abandon that wait - via PROCESS-INTERRUPT - whenever<br>
it wants to, so the global lock in my example above may be something a little<br>
different from a CCL lock.)<br>
<br>
I haven't needed to solve the SAMEFRINGE problem elegantly in a long<br>
time and when I hear terms like "a blocking wrapper around<br>
non-blocking I/O" I wonder if or how that differs from things like<br>
#_select or #_poll.  I'm willing to believe that there could be cases<br>
where coroutines (the ability to control the scheduling of a small<br>
number of threads relative to each other) could be useful,  but I think<br>
that that could be provided by fleshing out the interface that's sketched<br>
above.<br>
<br>
Lisp implememtations that provide(d) cooperative threads (I don't know<br>
of any implementations that still do so) typically provided a "lisp<br>
scheduler" on top of what I described above; that layer generally<br>
tried to do some sort of periodic preemption (so that a thread that<br>
hadn't yielded in a while was made to do so) and that layer was<br>
effectively spread all over the implementation (so that blocking<br>
operations were replaced with code which combined yielding and polling.)<br>
I would not want to see that kind of code reappear and if anyone's<br>
saying that they want that, I'm still very much at the "no, you don't"<br>
stage.<div class="im"><br>
<br>
<br>
On Mon, 12 Nov 2012, Andrew Lyon wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hello, I'm an avid CCL user (have been for over a year now). This is my<br>
first post on the dev list, and I did a lot of research on this topic before<br>
deciding to post to make sure this hasn't been covered before.<br>
Is there any interest in the ClozureCL community in having<br>
lightweight/cooperative threading available in the implementation? I have a<br>
few problems that would be a perfect fit for this (for instance, creating a<br>
blocking interface over non-blocking IO) and I'd love to not only voice my<br>
support for the feature, but also know if anybody else would also like<br></div>
something like this.?<br>
<br>
I think the most ideal implementation would be where you?explicitly?give up<div class="im"><br>
control of the current "micro-thread" to another known thread (on top of<br>
this, something like "yield" could be built in the app itself, if needed).<br>
Matching this to the way OS threads currently work would be awesome...for<br>
instance, unwind-protect would only work for the coroutine it's wrapping<br>
around, so if you give control to another coroutine, that unwind-protect<br>
won't fire if there is an exception. Obviously this would be a big feature,<br>
and probably at least a few people would have opinions on how it would be<br>
implemented, not to mention there's probably a lot going on under the hood<br>
that I'm not aware about...but I'd like to at least open a discussion.<br>
<br>
I did try to implement coroutines outside of CCL via libpcl/CFFI<br>
(<a href="http://xmailserver.org/libpcl.html" target="_blank">http://xmailserver.org/<u></u>libpcl.html</a>) but was met with much resistance and<br>
many segfaults.<br>
<br>
Although I'm not familiar with the internals of CCL more than reading the<br>
"Internals" page and most of the docs, I'm more than happy to try getting my<br>
hands dirty and add support myself with some guidance from others (where do<br>
I start, what are the caveats, has anyone else tried this, etc). I'd also<br>
like to know if this is possible using the Virtual Instructions in the<br>
compiler.<br>
<br>
I'd love to hear anyone's thoughts on this, and thanks for the great<br>
implementation.<br>
<br>
Andrew<br>
<br>
<br>
</div></blockquote>
</blockquote></div><br></div></div>