> 2. Since this is a "Windows thing", is there some reason why the execution
> of "file" or "file.exe" isn't handled as a special case in the exec call
> (and all its flavors) and no place else?
make, for example? If you have a rule that creates "foo" from foo.c,
gcc will actually create "foo.exe
On 2012-05-22 13:02, Corinna Vinschen wrote:
[...]
>> Testcase signal/kill:
>> Signals may or may not reach the correct thread with 1.7.12-1 and newer.
>
> Confirmed. I think the reason is that we only have a single event to
> signal that a POSIX signal arrived instead of a per-thread event, but
> I have experienced this problem several times. In my case it seemed
> to be a problem between 'Unix' and 'DOS' files. In each case, I have
> been able to fix it by editing the RCS file using vim and deleting all
> the extraneous carriage returns - :%s/^M$// Sometimes I've had
> to do it twice
> Out of curiosity would downloading setup.exe using wget also work
> around the problem?
Most likely. I don't think wget cares about protecting Windows users
from their own stupidity. If you use wget, you should know what you're
doing.
How about you just give it a try?
Otto
--
Problem report
> This is because of the file being downloaded from the web (check file streams
> for details).
> You can easily cleanup the file metadata by copying it to FAT drive (Flash
> disk/memory card).
The file stream with the "downloaded from the web" information can
easily be removed with the Stream t
> I have done some more checking and I might have been wrong about the
> Ubuntu and Linux in general. It looks like the formatting strings are
> incompatible between MSVC and *NIX. It appears that either %S (SUSv2)
> or %ls (C99) is needed on *NIX. MSVC switches the meaning of %s for
> wprintf() (
> `--> ./testvswprintf.exe
> this works, 1, 2, 3...
> but the following does not:
> ret: 1
> buf: >T<
>> T<
> ret: 4
> wcout: >THIS IS A TEST<
>
> The same code works well on both Ubuntu with GCC and on Windows with
> Visual Studio 2010.
I just tried your test with g++ (Ubuntu/Linaro 4.5.2-8ub
> The basic issue is that sem_wait() is being kicked out with EINTR
> extremely frequently (9 out of 10 times or more), which slows my code
> to a crawl as it repeatedly retries sem_wait() until it finally
> returns zero. In 1.7.9, it does not appear that sem_wait() is
> preempted in this fashion;
> Weird. I tried under CMD now as well, but it still runs and runs and
> runs, without a failure. Tested on XP, W7, and 2008 R2.
Maybe It’s Just Me then.
> Another idea is that your system also fails due to the problem reported
> in http://cygwin.com/ml/cygwin/2012-05/msg00522.html
> I'm just a
On 2012-05-24 13:19, Corinna Vinschen wrote:
> You know that Cygwin is just a user space DLL, right? There's no state
> information kept in the OS beyond the lifetime of any process using the
> Cygwin DLL. In case of pthreads, there's no state at all shared with
> other processes.
Yes, that’s ex
> My testcases for asynchronous and deferred cancel work on threads
> blocked in sem_wait() but still fail mostly on threads blocked in
> read(STDIN_FILENO, ...), same as before. Sorry about that.
I spoke too soon. There seems to be some kind of runtime decay and a
dependency on semaphore.h.
Runn
> I think I found the problem. I've uploaded a new snapshot. Please give
> it a try.
My testcases for asynchronous and deferred cancel work on threads
blocked in sem_wait() but still fail mostly on threads blocked in
read(STDIN_FILENO, ...), same as before. Sorry about that.
$ uname -v
20120523
>> Testcase cancel deferred:
>> Works with 1.7.9 and 20120517 snapshot, fails (hangs) with 1.7.12-1
>> and 1.7.15-1.
> If that works in the snapshot anyway, I'm not going to look into that
> one.
It worked in the reduced testcase with sem_wait(). With read() it’s
still half-broken. See below.
>>
> Would you mind to provide *simple* testcases to allow easy debugging
> of your observations?
I reduced the various tests to three rather simple individual testcases
because those show possibly different bugs.
Testcase cancel deferred:
Works with 1.7.9 and 20120517 snapshot, fails (hangs) with 1
> You should always try the most recent http://cygwin.com/snapshots.
Thanks for the suggestion, that did indeed change something: The tests
yield the same half-broken behaviour for pthread_cancel as with 1.7.7
and 1.7.9. That’s better than the almost completely broken behaviour
from 1.7.12-1 to 1.
Greetings,
as I got no response to my first question, I tried two older Cygwin
versions to narrow down the problem. Maybe this’ll help someone to
figure out the cause.
I tried 1.7.9 and 1.7.12-1, with the results of 1.7.12-1 being exactly
like the ones from 1.7.14-2 and 1.7.15-1. Unfortunately I
> Here's what is going on...
Here’s your solution:
http://lmgtfy.com/?q=unix+for+beginners
> When I enter:
>
> admin@mypc ~
> $cd
>
> admin@mypc ~
> $
The first guide on the search mentioned above already has the answer for you.
> or
>
> admin@mypc ~
> $dir
>
> admin@mypc ~
> $
Pretty much
Hi James,
> 1. Cygwin would need an additional function with a parameter to specify
> byte pipes (maybe you already added this, I have not checked the recent
> source code very much).
You just missed the announcement:
On 2012-05-10 08:28, Corinna Vinschen wrote:
[snip]
> I just released 1.7.15.
Greetings everyone,
while porting a project from Linux to Cygwin I noticed that pthread_cancel
was having trouble cancelling threads blocked on semaphores and reads
from stdin.
Another user had a similar problem a while ago:
http://sourceware.org/ml/cygwin/2011-01/msg00374.html
According to the
19 matches
Mail list logo
