Rob,
I'm not sure if this finding ever made it through here as such, but in my
experiments, nice-ing "mkisofs" up (negative nice value) and "cdrecord"
down (positive nice value) I could turn certain failure of a 270 MB
recording session into probable success. Still, the behavior was not ideal:
On Fri, 2002-11-29 at 13:00, Christopher Faylor wrote:
> 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
On Thu, Nov 28, 2002 at 06:45:18PM -0800, Randall R Schulz wrote:
>You mentioned "... on all flavors of Windows ...", suggesting that there
>are better options on certain varieties of Windows, so another alternative,
>perhaps less onerous (perhaps not) would be to use whatever OS-specific
>facil
Chris,
At 18:00 2002-11-28, you wrote:
...
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
On Fri, Nov 29, 2002 at 02:16:18AM +0100, thomas wrote:
>Christopher Faylor <[EMAIL PROTECTED]> 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 n
Christopher Faylor <[EMAIL PROTECTED]> 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.
> However, I'
Randall R Schulz <[EMAIL PROTECTED]> wrote:
> problem. In particular, you'll need to supply a patch script that will
> allow others to replicate your results and evaluate whether there are any
> potential problems with your solution that you're might be overlooking.
There's already my problem. I
Thomas,
I think that's unwarranted. You needn't be so pessimistic. You've done good
work in tracking down the source of an undesirable characteristic, but you
need to follow through.
Traditionally, the thing to do would be to write a single post (perhaps
under a new "Subject:" thread) in which
On Fri, Nov 29, 2002 at 01:26:00AM +0100, thomas wrote:
>well i guess nobody considers this a problem ... too bad for the
>cdrecord/cdrdao users out there.
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
well i guess nobody considers this a problem ... too bad for the
cdrecord/cdrdao users out there.
thomas
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:
Ok now i really found the problem. If i always return from
fhandler_base::ready_for_read with 1 at the first line and skip all the
checks in there everything works.
$ time cat test.iso | nice -0 dd of=/dev/null
352512+0 records in
352512+0 records out
real0m5.528s
user0m2.155s
sys 0m
It seems to be a mystery whats going on, at least i'm not clever enough
find it out :(
Both sides of the pipe (cat and dd) wait at the same time, but what for?
Is one waiting for the other and vice versa? I have no idea. Look here:
23 2139047 [main] cat 3660 fhandler_base::write: binary write
Christopher Faylor <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 28, 2002 at 01:20:46AM +0100, thomas wrote:
>>Christopher Faylor <[EMAIL PROTECTED]> wrote:
>>
>>> If there is no data in a pipe it can wait for 10ms waiting for it, yes.
>>> See ready_for_read/peek_pipe in select.cc.
>>
>>Yep i saw the S
On Thu, Nov 28, 2002 at 01:20:46AM +0100, thomas wrote:
>Christopher Faylor <[EMAIL PROTECTED]> wrote:
>
>> If there is no data in a pipe it can wait for 10ms waiting for it, yes.
>> See ready_for_read/peek_pipe in select.cc.
>
>Yep i saw the Sleep (10) and though the same thing, but i figured that
thomas <[EMAIL PROTECTED]> wrote:
>26 245082 [main] dd 3100 readv: DEBUG 1.a syscalls.cc
>23 245105 [main] dd 3100 readv: DEBUG 1.b syscalls.cc
>23 245128 [main] dd 3100 readv: DEBUG 2.a syscalls.cc
>23 245151 [main] dd 3100 readv: readv (0, 0x240FD9C, 1) blocking, sigcatchers
Christopher Faylor <[EMAIL PROTECTED]> wrote:
> If there is no data in a pipe it can wait for 10ms waiting for it, yes.
> See ready_for_read/peek_pipe in select.cc.
Yep i saw the Sleep (10) and though the same thing, but i figured that
can't be it when i commented it out, compiled a new cygwin1.d
On Wed, Nov 27, 2002 at 10:39:05PM +0100, thomas wrote:
>10 ms delay, and there's many of them. Exactly every 612 lines or every
>34816 bytes (34kb). Which is about 210 seconds delay on a 700MB file.
If there is no data in a pipe it can wait for 10ms waiting for it, yes.
See ready_for_read/peek_p
Hi List,
I'm back with more information, I've narrowed down the problem further
with another strace session. I've run:
cat test.iso | strace -o dd1.log nice --1 dd of=/dev/null
cat test.iso | strace -o dd0.log nice --0 dd of=/dev/null
nice --1 needs much longer, like already shown in another th
> Randall R Schulz <[EMAIL PROTECTED]> wrote:
> I don't know what sort of system you're using, but as desktops go, mine's
> pretty high-performance: 2.4 GHz processor, PC 3100 RAM; dual-channel
> Ultra-160 SCSI controller with fast disks segregated from slow ones; CD
> recorder on SCSI. I have
Thomas,
At 14:04 2002-11-22, you wrote:
...
now please correct me if i'm wrong, but when it works with 1.1.18 and not
with 1.3.x and the only constant that changes is cygwin, wouldn't every
fan of logic scream out loud then: it's cygwin! :)
Don't bite my head off, Tuvok, but your "logic" is f
On Fri, Nov 22, 2002 at 11:04:15PM +0100, thomas wrote:
>Christopher Faylor <[EMAIL PROTECTED]> wrote:
>>If the relevant code was obvious then it would be trivial to fix. I'm
>>not even convinced that there is a cygwin problem here. It doesn't
>>appear to be doing anything wrong. However, unless
Christopher Faylor <[EMAIL PROTECTED]> wrote:
> If the relevant code was obvious then it would be trivial to fix. I'm
> not even convinced that there is a cygwin problem here. It doesn't
> appear to be doing anything wrong. However, unless you are doing something
> with ttys I don't see why tha
On Fri, Nov 22, 2002 at 10:00:59PM +0100, thomas wrote:
>well i'm a bit lost here. can someone point me in some direction what
>to do next? where is the relevant code, i figured it must be pipe.cc
>and tty.cc or is there some other place?
If the relevant code was obvious then it would be trivial
well i'm a bit lost here. can someone point me in some direction what to
do next? where is the relevant code, i figured it must be pipe.cc and
tty.cc or is there some other place?
also do i have to recompile the binaries when i build a new cygwin1.dll
to test the changes?
thomas
--
Unsubscribe
Max Bowsher <[EMAIL PROTECTED]> wrote:
> thomas <[EMAIL PROTECTED]> wrote:
>> it seems that the pipe code with recent cygwin versions causes a
>> performance problem when much data (3.6 MB per second in this case) is
>> transferred from one program to another.
>>
>> i use mkisofs to make an iso f
thomas <[EMAIL PROTECTED]> wrote:
> it seems that the pipe code with recent cygwin versions causes a
> performance problem when much data (3.6 MB per second in this case) is
> transferred from one program to another.
>
> i use mkisofs to make an iso filesystem from files on the fly and pipe
> the
hello,
it seems that the pipe code with recent cygwin versions causes a
performance problem when much data (3.6 MB per second in this case) is
transferred from one program to another.
i use mkisofs to make an iso filesystem from files on the fly and pipe
the output directly to cdrecord which writ
27 matches
Mail list logo
