From: Tanaka Akira Date: 2005-08-26T12:16:14+09:00 Subject: Re: [ANN] EventLoop 0.0.20050825.1600 In article <87k6i9rifs.fsf@wigwam.deepwood.net>, Daniel Brockman writes: > In a callback-based system, you have to deal with callbacks. > In a preemptively multithreaded system, you have to deal > with synchronization. It's a tradeoff, and largely a matter > of taste, preference and familiarity. It seems that a giant lock can be some compromise of them. (like GIL of Python) Apart from that, Ruby's IO methods are not so good for event loop. You may have frustration when you find that some methods block even if O_NONBLOCK is set. The blocking behavior is good for threaded programs. The context switch behind the blocking is enough to do some works because the works are held by other threads. So the blocking behavior makes threaded programs happy even if O_NONBLOCK is set. Anyway O_NONBLOCK is required to avoid entire process blocking on write operation. However the behavior is bad for event loop style programs. Because the works are held by the event loop in the caller's thread. So I think it is good to have both blocking methods and nonblocking methods. The nonblocking methods should make event loop style programs happy. However it is not accepted by matz because good names for nonblocking methods are not found yet. Recently I proposed connect_nonblock, nonblock_connect, nbconnect for nonblocking connect but they are rejected. -- Tanaka Akira