From: Bill Atkins <batkins57@...>
Date: 2005-08-11T00:28:17+09:00
Subject: Threading on Win32 - at an impasse

I'm working on a project that would have to run several TCPServer's in
the background while accepting input from the user; it has to run on
both Win32 and UNIX.

It runs without issue on UNIX, but I can't think of any clean way to
get this arrangement to work on Win32.  If I use threads for the
servers, these threads will all block while the main thread is waiting
for input for the user (I'm using readline, so I don't think the kbhit
and getch hack (mentioned in another thread I started) would work
without giving up the functionality of readline).   The servers in the
threads will not handle input until readline gets a whole line from
STDIN. Win32::Thread doesn't support more than one thread at a time,
so Ruby's builtin Threads remain the only solution along these lines.

If I use separate processes for the servers, interprocess
communication gets a bit messy, and there is also the issue of
Win32::Process segfaulting whenever I attempt to kill a process (the
application must be able to kill its child processes).  Separate
processes introduce a lot more complexity than is really necessary for
this project.

My other option is to package the Cygwin DLL and the Cygwin ruby
binaries with my application, since Cygwin doesn't have blocking
issues that arise with native Win32.  The trouble is that I also have
a Gtk interface, and I suspect that running Gtk through Cygwin's X
server would be a nuisance, in addition to bloating the distribution
considerably.

Is there some elegant way to wait for user input while having
networking threads running in the background?

--
Bill Atkins


-- 
Bill Atkins