On 3/11/2020 12:30 PM, Brian Inglis wrote:
On 2020-03-11 00:13, Eliot Moss wrote:
On 3/11/2020 1:31 AM, Brian Inglis wrote:
There are gcc bugzilla comments about requiring gcc to be built with glibc
libatomic to guarantee indirect inline functions support, and presumably glibc
detecting gcc i
Hi Corinna,
Am 11.03.2020 um 20:51 schrieb Corinna Vinschen:
> Hi Takashi,
>
> would you mind to take a look? The mutex is only used in
> fhandler_pty_master::pty_master_fwd_thread if the pseudo console is
> used. Unfortunately I don't see the faintest hint in the starce why
> this occurs. It
On 2020-03-12 02:08, Norton Allen wrote:
Correct me if I am wrong, but O_NDELAY is not the same as O_NONBLOCK
At least for cygwin those two are exactly the same... I think...
#define _FNONBLOCK 0x4000 /* non blocking I/O (POSIX style) */
#define _FNDELAY _FNONBLOCK /* non blo
On 3/11/2020 9:04 PM, Åke Rehnman via Cygwin wrote:
On 2020-03-11 22:55, Brian Inglis wrote:
VMIN > 0 || VTIME > 0 implies blocking; O_NONBLOCK implies SIGIO
delivery; see:
https://www.tldp.org/HOWTO/pdf/Serial-Programming-HOWTO.pdf
https://www.cmrr.umn.edu/~strupp/serial.html
htt
On 2020-03-11 22:55, Brian Inglis wrote:
VMIN > 0 || VTIME > 0 implies blocking; O_NONBLOCK implies SIGIO
delivery; see:
https://www.tldp.org/HOWTO/pdf/Serial-Programming-HOWTO.pdf
https://www.cmrr.umn.edu/~strupp/serial.html
https://en.wikibooks.org/wiki/Serial_Program
On 3/11/2020 5:55 PM, Brian Inglis wrote:
VMIN > 0 || VTIME > 0 implies blocking; O_NONBLOCK implies SIGIO delivery; see:
While I agree with everything else you said there, I don't believe
either of these are true, unless by 'implies' you mean that's how you
usually do it. I have done a lot o
On 2020-03-11 14:48, Åke Rehnman via Cygwin wrote:
> opening a file (serial port) with O_NONBLOCK and subsequently setting termios
> VMIN and VTIME > 0 makes read() never ever return any data (returns EAGAIN
> indefinitely).
> Don't ask my why one would want to do something like this but apparently
Hello all,
opening a file (serial port) with O_NONBLOCK and subsequently setting
termios VMIN and VTIME > 0 makes read() never ever return any data
(returns EAGAIN indefinitely).
Don't ask my why one would want to do something like this but apparently
the "screen" program think this is a goo
Hi Takashi,
would you mind to take a look? The mutex is only used in
fhandler_pty_master::pty_master_fwd_thread if the pseudo console is
used. Unfortunately I don't see the faintest hint in the starce why
this occurs. It happens pretty early at startup.
Thanks,
Corinna
On Mar 11 18:47, Achi
Achim Gratz writes:
>>> There is some undesirable interaction when I try to start mintty from my
>>> desktop shortcut. Mintty itself starts OK, but any Cygwin program that
>>> mintty starts (whether a shell or something else) just goes into a
>>> spinloop (Windows says it's mostly kernel time).
U
Eliot Moss writes:
> What I am really reporting is that Cygwin is giving the pthread mutex form
> when it should not be. My CPU clearly has the capability, and the compiler
> clearly
> knows how to emit the instruction, since the __sync form does it. What is
> mysterious and tangled is why libat
On 2020-03-11 00:13, Eliot Moss wrote:
> On 3/11/2020 1:31 AM, Brian Inglis wrote:
>
> A quick followup: I was able to get __sync_val_compare_and_swap_16 to work
> (and its bool form). That will do for now, though of course it's
> deprecated.
>
> This does get me the inlined asm cod
12 matches
Mail list logo
