From: adam AT appleby DOT com ("Adam Miller") Subject: Re: ITIMER Implimentation??? 9 Dec 1996 15:11:25 -0800 Sender: daemon AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <9612091613.AA19730.cygnus.gnu-win32@smtp.appleby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Original-To: X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Original-Sender: owner-gnu-win32 AT cygnus DOT com > 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 adam AT appleby DOT com - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".