Subject: Re: ITIMER Implimentation???
From: [email-masked] ("Adam Miller")

9 Dec 1996 15:11:25 -0800
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Original-To: <[email-masked]>
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Original-Sender: [email-masked]

> Hopefully, You are not right :-) Win32 API is huge, and contain all 
> neccessary functions. And asyncronous timer events too. You may use 
> SetTimer(NULL,...). It seems to me, _every_ unix system call may be 
> emulated with Win32 API functions! BTW, what about to implement vfork() 
> using threads mechanism and fork() with copy-on-write semantic using
memory 
> mapped files?-)
> 
One problem with using SetTimer is the application is required to have a
Message loop (or at least required to call DispatchMessage() in order
to dispatch the messages).  Even in you set the HWND parameter to NULL,
Windows still delivers the message through the loop.

This is a problem for server based apps, like an nfs server, where you
have no user interface.

I believe the MM timer routines work as advertised and don't even
require any MM devices in the box.  Other timer alternatives would be to 
hook your app at the point of entering an alertable wait state that
provides
timeout capabilites(eg. select, WaitFor..., sleep, Sleep (Win32 version).
Similar to the Xt way of doing timers.

Also mentioned on this list is the ACE library, which provides a framework
for these kinds of issues (Asynch IO, timers, threads, etc...)

However the original poster poses a different problem, he wants to time out
an IO operation.  Asynchrounous timers like the ones provided with SetTimer
or even XtAppAddTimeout() are intended to solve a different pupose.
Since the NT world is alien to signals, it seems the best way to solve this
issue is to isolate your timed I/O routine and provide a suitable port
to Win32 using the native Win32 calls.  Or even in a unix portable way,
set the fd to nonblock, start your IO call, block in select with a timeout.

It's not that signals are evil, in the unix world we have little choice 
at times in getting the OS to notify us of certain events.  When I started
working with NT, there were different methods to get the OS to alert.
I don't really beleive one is better than the other (although if I can
really figure out how to use SEH, I'd probably lean there.  I've been
in the unix world for too long).

I sometimes wish that Sun would put some of these concepts into Solaris.
Especially all the different ways to allocate memory in NT.  These are
some good abstractions that save much work.  If I had the Heap API
functions
on unix my life would be happier.  One thing that really bugs me is
heap fragmentation.  Using mmap to act as a general purpose memory
allocator
is troublesome.  sbrk just dont cut it any more.

One bright side is the Posix 4 spec.  They're really trying to brin some
new
concepts to the unix world.  However Posix has it's problems with
acceptability, and MS probably will never accept it.

Off the soapbox...thanks, I needed that.

Adam Miller
royalblue technologies
[email-masked]
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".