Carl Banks <pavlovevide...@gmail.com> writes: > > I don't think the concept of "drivers" applies to user-mode programs. > > For FFI calls you would use an OS thread. > That's contrary to the hypothesis, isn't it?
Yeah, it would have been better to say, green threads are ok for most typical forms of i/o concurrency, but OS threads are still necessary for some things. An FFI call in particular isn't exactly under the control of your language's runtime system; it has to be treated more like an external program. OS thread switching is much more expensive than green thread switching, so it's still preferable to use green threads when possible. > > The language runtime switches between busy computation threads on > > a timer tick. > This would seem to result in a tradeoff between performance and low- > latency. GHC appears to use a 100 hz timer, which I'd expect to be fast enough for interactive applications while still not causing too much cpu load. I don't know if it has a way to assign priorities to microthreads (e.g. if you have one running your program's GUI) though. I don't think either Python or GHC can implement hard-real-time latency because they both use stop-the-world garbage collection. E.g. in Python, releasing the last reference to a large list or dict can take a long time. > And Paul, if I'm being a little hard on you here, it's not that I'm > taking issue with your own claim so much as with your dismissal of > mine. Well, the issue was why Python uses native threads pervasively. As far as I can tell, it's just an implementation artifact that has no really compelling justification. -- http://mail.python.org/mailman/listinfo/python-list
