Mail Archives: cygwin/2002/11/28/20:59:51
On Fri, Nov 29, 2002 at 02:16:18AM +0100, thomas wrote:
>Christopher Faylor <cgf AT redhat DOT com> wrote:
>> You're aware that it is a major holiday in the US, right? Guess what?
>> I'm in the US. You shouldn't expect instant responses to your musings
>> even in the best of times but certainly not now.
>
>I'm sorry, I wasn't really aware of it.
How about the other part? Like expecting answers within hours after you
send something? Nothing to say there? I guess you're just the impatient
type.
>>However, I'll go on record by saying that I haven't seen anything which
>>indicates that there is a bug in cygwin. Hmm. Sounds like something I
>>might have said before.
>
>Yes you did. However i don't understand why you don't see this as a
>bug or even consider it a problem. With all the tests and IMHO
>evidence i presented this really boggles my mind. I'd honestly like to
>hear why you don't think cygwin is at fault here.
I'd honestly like to hear why you boggle at the concept that anyone
would point out the place where the 10ms delay occurs, and then, when
the 10ms delay was re-presented, say "Oh! That 10ms delay which I
pointed you at is a problem!"
>> If it is a problem with the 10ms delay in select.cc then I really don't
>> know how to solve it. If you have ideas, you should post them.
>
>Now that's finally a statement on the issue.
I guess you're looking for a longer answer. Let me take some of my
holiday time to present one.
ready_for_read is called for certain devices prior to actually reading
from the device. It's purpose is to provide an interruptible method
for "blocking" prior to reading since cygwin's signals need to act like
UNIX signals and there is no real way to emulate signals on all flavors
of Windows with anything other than smoke and mirrors.
With pipes, the only way that I'm aware of to "block" in this fashion
is a poll loop where PeekNamedPipe is called to see if there is anything
available. If there is nothing available then the poll loop will wait
for either 10ms or until a signal arrives. If no signal arrives, the
loop continues, otherwise it exits.
In some (and only some) previous versions of cygwin, I had the bright
idea of avoiding the ready_for_read stuff when there were no signal
handlers in the program since I thought (erroneously) that signals would
either be ignored or terminate the program in this scenario. Maybe this
is why a previous of cygwin would work with cd writers. I don't know.
However, it is not the case that the only thing that a signal can do is
either be ignored or cause the process to terminate. A signal can also
cause the process to stop. So, allowing a pipe to block in a ReadFile
means that the process cannot be stopped. That's not allowable.
So, what you are calling a "problem" is undoubtedly one of the many
compromises that Cygwin has to make in the interests of UNIX
compatibility which, I believe, is what I have been maintaining all
along.
Of course, it is entirely possible that there is something wrong with
the logic in cygwin and that a pipe is waiting 10ms for every read or
something like that. I don't know. I don't see how that's possible
from the code in ready_for_read but it's certainly at least a
possibility.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -