Subject: RE: ITIMER Implementation???
From: [email-masked] (Alessandro Forin)

4 Dec 1996 12:00:37 -0800
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <c=US%a=_%p=msft%l=[email-masked]>
Original-To: "'Jeremy Allison'" <[email-masked]>,
        "'Colin Peters'"
	 <[email-masked]>
Original-Cc: "'GNU-Win32'" <[email-masked]>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 88 TEXT
Original-Sender: [email-masked]

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:[email-masked]]
>Sent: 	Wednesday, December 04, 1996 12:19 AM
>To: 	'Jeremy Allison'
>Cc: 	'GNU-Win32'
>Subject: 	RE: ITIMER Implementation??? 
>
>Jeremy Allison[SMTP:[email-masked]] 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 - [email-masked]
>-- 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
>"[email-masked]" with one line of text: "help".
>
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".