From: sandrof AT MICROSOFT DOT com (Alessandro Forin) Subject: RE: ITIMER Implementation??? 4 Dec 1996 12:00:37 -0800 Sender: daemon AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: Original-To: "'Jeremy Allison'" , "'Colin Peters'" Original-Cc: "'GNU-Win32'" X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 88 TEXT Original-Sender: owner-gnu-win32 AT cygnus DOT com My suggestion was just for ITIMER, not for signals in general. [That is what the original request was for.] One idea you could play with is to have a separate thread doing all the I/O, and the main thread wait on an event. Either I/O completion or a signal would wake the main thread. I am not sure how this would pan out with terminal I/O [is your TTY code POSIX ?], and it sure stinks of slow but it might require less widespread changes, donno. 8-O I know that implementing signals is a pain, that's part of what I meant by "Signals are bad for you". I have hacked U*x kernels ever since 4.1, and signals got very much in the way of everything. I also meant that signals are a poor substitute for 3 different things: exceptions, asynchronous I/O, and multithreading. They are not good enough for exceptions a-la C++ try-except/catch-throw or SEH in Win32 because they are too expensive: exception support needs a very light-weight mechanism that languages can use at the block-of-code level. The need to distinguish which file is I/O ready makes it quite cumbersome to use signals for asynchronous I/O, and then again not all Unixes support this feature anyways [correct me if wrong]. In all practical cases select() and/or a separate thread works much better. I do hope there is no need to explain why multithreading is better than signals for writing 'parallel' programs. Oh, I forgot that signals are also used for IPC...so make that "a poor substitute for 4 different things". As for what "programming style" signals lead to. Have a look at the original csh(ell) [4.1/4.2], and see how much you think you understand of it. Then if you could debug it (you probably cant because of what it does to the tty) you'd find out it works in a totally different way. "Most programs only do very simple things with signals" : my point exactly. 8-i sandro- >---------- >From: Colin Peters[SMTP:colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp] >Sent: Wednesday, December 04, 1996 12:19 AM >To: 'Jeremy Allison' >Cc: 'GNU-Win32' >Subject: RE: ITIMER Implementation??? > >Jeremy Allison[SMTP:jra AT cygnus DOT com] wrote: >>the problem is that UNIX code expects that synchronous I/O >>will be interrupted when a signal occurs. Don't tell me it's >>bad, that's just the way UNIX code is written, and that's the >>way people using Cygwin32 will want it to work :-). Cygwin32 >>is not currently MT-safe (that's another bunch of code :-). >> >>This is not possible on NT currently without me re-writing >>all blocking I/O in Cygwin32 to use asynchronous I/O under >>the covers and waiting on the handle and a separate event >>which the signal thread sets as 'signalled'. This is a lot >>of work, hence my statement. > >It's even worse than that. Asynchronous I/O is not supported >under Windows 95. If you want it to work right under 95 (and >I for one really do want it to work under 95) and under NT >you are definitely in for some long nights ahead. > >On the other hand, I just want to be able to compile code >that runs under 95, not necessarily use the Cygnus library, >so I have less problems with this. But I think I'm in the >minority there. > >Colin. > >-- Colin Peters - colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp >-- Saga University Dept. of Information Science >-- Fundamentals of Information Science >-- http://www.fu.is.saga-u.ac.jp/~colin/home.html > >- >For help on using this list, send a message to >"gnu-win32-request AT cygnus DOT com" with one line of text: "help". > - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".