From: rdlugosz.1044583@... Date: 2004-08-31T11:52:16+09:00 Subject: Two issues with webrick - both threading & OS related All - I've recently been playing with a simple webrick servlet that will allow me to build playlists and stream mp3s off of my home system. I've ran into some very peculiar issues that appear to be thread & OS related. It seems that on Linux, my program will only handle *one* connection at a time; i.e. - if your media player is streaming a file, the browser cannot load the pages to look at other music directories. However, on WinXP I can have several simultaneous connections to the system & there are no blocking issues. The media program aside, working with Jim Weirich today we discovered some other interesting things. A absolutely basic webrick servlet that has a Thread.sleep in it's do_get will block all access to the servlet on any OS - the blocked request will execute immediately upon the blocker completing. Here's the code: class SleepServer < HTTPServlet::AbstractServlet def do_GET(req, res) sleep(30) res.body = '

DONE

' end def do_POST(req, res) do_GET(req, res) end end This seems pretty strange; it's as if webrick is operating in a "Single thread model" servlet mode. I'm sure that's not the correct behavior. Finally, another issue we ran into is one somehow related to threads and IO and is OS specific. The code below executes properly on Linux, but appears to deadlock on XP. class Streamlet < WEBrick::HTTPServlet::AbstractServlet def do_GET(req, res) res["content-type"] = "text/plain" reader, writer = IO.pipe Thread.start{ 1000.times{|i| puts i writer << "a" * 1000 writer << "\n" } writer.close } res.body = reader end end Personally, I think this problem is even more strange, since Ruby is handling the threads internally it doesn't seem like it should deadlock on one OS and not the other. The issue I'm having with my media player is strange too, since it has problems only on Linux yet our test code (the sleep(30) servlet) is broken on both platforms... Sorry for the length of the email, but I felt the detail was required. I appreciate any suggestions you may have. -Ryan ryan@dlugosz.net