From: Francis Cianfrocca Date: 2006-05-21T21:45:38+09:00 Subject: Re: sysread changes behavior in the presence of threads? I'm working on the eventmachine library (see rubyforge). The goal is to enable complicated applications (including multiplayer games and network servers) that are far faster and more scalable than is possible with "ordinary" Ruby coding. (That is, without requiring deep understanding of the Ruby runtime environment in order to get the required performance.) Practically speaking, this requires strict nonblocking i/o and a certain amount of C extensions. We'd like for any Ruby programmer to be able to write a large, fast application without acquiring expertise in concurrency and networking issues. As an example, I'm responsible for an LDAP system with five replicated servers running simultaneously and sharing load. This system now can sustain rates of 2000 queries per second per server (directory size is about one million entries), but I had to resort to a single-threaded server handwritten in C++ (openldap's performance on the specified hardware was about one-twentieth of the requirement). The replication code is almost all in Ruby. I'd like to have the main server code be largely in Ruby so it will be easier to maintain. That's an example of what I want to do. As far as threads are concerned: I'm one of those people who believe that threads are seriously overused and should be avoided, especially in high-performance applications. But occasionally if you're mixing Ruby and native code, you may have threads in each. As long as Ruby's threads are green, this split will exist, and it would be nice to able to synchronize a Ruby thread with a native one. On 5/21/06, Robert Klemme wrote: > 2006/5/21, Francis Cianfrocca : > > It's a Windows issue, nothing to do with Ruby. I haven't looked at how Boost > > implements them, but if I have a chance I will. The problem is with timed > > condwaits. As you know Windows uses different synch primitives than Unix. > > It's one of those tiny breaches of atomicity that you'll occasionally see if > > you run enough trials on a machine with enough multiprocessors. > > But this does not bite you if you use Ruby's condition variables as > they are completely in Ruby land and there are no native threads > (well, *one* native thread is there :-)) > > This whole thread makes me wonder why at all you need to use sysread > and a non blocking variant of it. Do you have any extensions that use > native threads or what are you trying to accomplish? I'm asking > because for me Ruby's threads and blocking IO (on Ruby level) have > served me well so far. > > Kind regards > > robert > > > -- > Have a look: http://www.flickr.com/photos/fussel-foto/ > >