(I'm the original poster of the question above -- sorry, didn't notice I wasn't logged in when I pressed save.)

pg: Yes, as bbfu guessed, the code I posted is a test-case to show the problem.

Originally, my program read a number of sensors and then distributes the data out over sockets to multiple clients. As some of the sensors are accessed using TCP as well, the program needs to act as a socket server AND a socket-client at the same time. I therefore wrote everything around a select() in perl since I can't afford anything to block in the program. That program works fine.

Recently, I've needed to do a simulator for the system, whereby instead of reading data from sensors and distributing it out to clients, an operator would be able to control the values on-the-fly. So I am migrating the original program into a Tk environment with a dynamic GUI front-end. As Tk has a select() at its heart, and that select() can be tapped into using fileevents, the overall model should not be much different from my original program.

bbfu - I tried running it under Window and found the same problem of accept() blocking. Strange -- Under Redhat, the listening socket is not "readable" until a client connects, and only then does it pass control to the server_read() function, and so accept() doesn't block. My original program is able to handle multiple events without blocking. Even the Tk version on Linux works fine -- the GUI is operational and doesn't block. It only bombs with the error above when I try to set a "writable" fileevent on the client socket ... even then the MainLoop is still active and the GUI and other events go on fine (multiple clients can still connect).