From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heribert Dahms To: 'Chris Faylor' Cc: "Fifer, Eric" , 'Ray Easton' , cygwin@sourceware.cygnus.com Subject: RE: call_handler, interrupt_now and interruptible Date: Mon, 07 Feb 2000 15:23:00 -0000 Message-id: <99B82AA9708ED0119B55006097125A002DE8F9@ifk63.mach.uni-karlsruhe.de> X-SW-Source: 2000-02/msg00110.html Hi Chris, you are are right, I said "I guess" and have not actually seen any misbehavior. Indeed, I have a single source file with a main() and no DLL of my own at all. I'll test it as soon as I can find another PC which I can unplug from network while running without one of my collegues killing me... Sorry for the false "alarm" 8-) Bye, Heribert (heribert_dahms@icon-gmbh.de) > -----Original Message----- > From: 'Chris Faylor' [SMTP:cgf@cygnus.com] > Sent: Saturday, February 05, 2000 00:26 > To: Heribert Dahms > Cc: Fifer, Eric; 'Ray Easton'; cygwin@sourceware.cygnus.com > Subject: Re: call_handler, interrupt_now and interruptible > > On Fri, Feb 04, 2000 at 10:45:14PM +0100, Heribert Dahms wrote: > >I guess this breaks now my code, which basically does a select() > until > >a socket becomes readable, starts a loop preparing a timeout with > >alarm(60) for the following blocking fgets(), which is normally reset > >using alarm(0) after each line, but is supposed to be interrupted in > >case of a bad behaving client? > > Why have you reached this conclusion? Have you actually > noticed this behavior? The changes that I made should not > have eliminated functionality in anything but DLLs and > that is only temporary. > > If this is just supposition, then try the cygwin DLL. There > is no need to speculate about things breaking if you haven't > actually checked the code in question. > > cgf -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com