On Jul 22, 5:27 pm, Paul Rubin <http://phr...@nospam.invalid> wrote: > Carl Banks <pavlovevide...@gmail.com> writes: > > I don't think your fantasy async-only all-green-thread langauge > > implementation is possible anyway. > > Erlang and GHC both work like that, quite successfully: > > http://shootout.alioth.debian.org/gp4/benchmark.php?test=threadring&l...
I am not suggesting that you can't do a lot of things with async I/O. But can you do *everything* that native threads can do? I don't think so. So when you asked: "Why is that [native threading] such an advantage? Green threads work fine if you just organize the i/o system to never block." Well, the answer is they don't always work fine. Just organizing the I/O system never to block won't cut it, since things other than I/O block. For green threads to work fine all the time you have to be able organize your entire system never to block, and I don't think it's possible on the common OSes in use today. Until that happens, there will always be advantages to being able to use native threads on a single core. > > How would you wait on a pipe in one thread, a socket in another, a > > semaphore in a third? > > You can select on pipes and sockets, I think. Not sure about > semaphores. So you made a claim that "green threads work fine", and rhetorically suggested that native threads had no advantages, yet you're not even 100% sure you can select on both pipes and sockets (both common forms of I/O), let alone semaphores? [You can select on sockets and pipes in Unix, not in Windows, although on Windows I think there are other ways to do it besides the select call.] > > (Are there any popular OSes that offer a unified polling interface to > > all possible synchronizations?) And what do you do about drivers or > > libraries that make underlying blocking calls? What if you have a > > busy calculation going on in the background? > > 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? > 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. Well that happens at the OS-level too but the OS can respond to interrupts and task switch between timer ticks at finer intervals. Back in my DOS days I wrote user programs that responded to I/O interrupts, but it doesn't seem to be common practice in modern OSes to easily allow this. 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. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
