`No data` on files with more than 1000 lines

[sasha-alias]

`No data` on files with more than 1000 lines

[okbob]

Hi čt 1. 2. 2024 v 15:39 odesílatel Sasha Aliashkevich < ***@***.***> napsal:

Hi Pavel, I'm observing a weird issue with files containing more than 1000 records. Steps to reproduce: $ psql -c "select n from generate_series(1, 1000) n" > test.txt $ pspg test.txt No data If I pipe the data directly to pspg then it works fine: $ psql -c "select n from generate_series(1, 1000) n" | pspg Also it doesn't work when I stream data from file: # session 1 $ pspg test.txt --stream #session 2 $ psql -c "select n from generate_series(1, 1000) n" > test.txt Session 1 has no data displayed. If I write less than 1000 records, 900 for example, then it works just fine. PS Thanks for the great job on pspg. It's really cool software!

I cannot to reproduce it on master branch on Linux (FedoraOS) What is your os? What is result of pspg --info Can you run pspg with the option --log=log? What is the content of the log? ***@***.*** ~]$ pspg test.txt --log=log ***@***.*** ~]$ cat log Čt, 01 úno 2024 18:19:30 +0100 [79139] started Čt, 01 úno 2024 18:19:30 +0100 [79139] with utf8 support Čt, 01 úno 2024 18:19:30 +0100 [79139] esc delay = -1 Čt, 01 úno 2024 18:19:30 +0100 [79139] DataDesc is initialized Čt, 01 úno 2024 18:19:30 +0100 [79139] next row will be data row Čt, 01 úno 2024 18:19:30 +0100 [79139] progressive load stop on 500 row Čt, 01 úno 2024 18:19:30 +0100 [79139] read rows 500 Čt, 01 úno 2024 18:19:30 +0100 [79139] set fallback_last_data_row to 498 Čt, 01 úno 2024 18:19:30 +0100 [79139] read input 500 rows Čt, 01 úno 2024 18:19:30 +0100 [79139] terminal size by TIOCGWINSZ rows: 51, cols: 136 Čt, 01 úno 2024 18:19:30 +0100 [79139] ncurses started Čt, 01 úno 2024 18:19:30 +0100 [79139] kmous=\E[<, TERM=xterm-256color Čt, 01 úno 2024 18:19:30 +0100 [79139] xterm mouse mode 1002 will be used Čt, 01 úno 2024 18:19:30 +0100 [79139] xterm mouse mode 1002 activated Čt, 01 úno 2024 18:19:30 +0100 [79139] initial stdscr size - maxy: 51, maxx: 136 Čt, 01 úno 2024 18:19:30 +0100 [79139] sleep 10ms per 1000 rows Čt, 01 úno 2024 18:19:30 +0100 [79139] next row will be desc row Čt, 01 úno 2024 18:19:30 +0100 [79139] read rows 1007 Čt, 01 úno 2024 18:19:30 +0100 [79139] process command: Invalid Čt, 01 úno 2024 18:19:31 +0100 [79139] process command: Quit Čt, 01 úno 2024 18:19:31 +0100 [79139] releasing cmd bar before end Čt, 01 úno 2024 18:19:31 +0100 [79139] xterm mouse mode 1002 is deactivated Čt, 01 úno 2024 18:19:31 +0100 [79139] ncurses ended Čt, 01 úno 2024 18:19:31 +0100 [79139] correct quit I have access only to Linux and not too old bsd, and there I don't see a problem. Unfortunately I do not have access to macOS, so I cannot test it, and it is hard to fix some bugs there. There is an option --no-progressive-load - does it help? Regards Pavel

…

— Reply to this email directly, view it on GitHub <#237>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEFO42DJPRTE6BN5UDUH2DYROSKFAVCNFSM6AAAAABCVAXWCOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGEYTENRYHEZTOOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sasha-alias]

Yeah, it's MacOS.

$pspg --info
pspg-5.8.1
with readline (version: 0x0802)
with integrated menu
ncurses version: 6.4, patch: 20221231
ncurses with wide char support
ncurses widechar num: 0
wchar_t width: 4, max: 2147483647
with ncurses extended functions support no: 20221231
without ncurses extended colors
with postgres client integration
without inotify support
with kqueue support
Darwin MacBookPro18 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000 arm64

$ pspg test.txt --log=log.log
No data
$ cat log.log
Thu, 01 Feb 2024 18:57:49 +0100 [59149] started
Thu, 01 Feb 2024 18:57:49 +0100 [59149] with utf8 support
Thu, 01 Feb 2024 18:57:49 +0100 [59149] esc delay = -1
Thu, 01 Feb 2024 18:57:49 +0100 [59149] DataDesc is initialized
Thu, 01 Feb 2024 18:57:49 +0100 [59149] sleep 10ms per 1000 rows
Thu, 01 Feb 2024 18:57:49 +0100 [59149] cannot to read from file (Operation timed out)
Thu, 01 Feb 2024 18:57:49 +0100 [59149] xterm mouse mode 1002 is not active
Thu, 01 Feb 2024 18:57:49 +0100 [59149] No data

Let me know if I can help somehow with debugging it.

PS
--no-progressive-load doesn't help (

[okbob]

čt 1. 2. 2024 v 19:00 odesílatel Sasha Aliashkevich < ***@***.***> napsal:

Yeah, it's MacOS. $pspg --info pspg-5.8.1 with readline (version: 0x0802) with integrated menu ncurses version: 6.4, patch: 20221231 ncurses with wide char support ncurses widechar num: 0 wchar_t width: 4, max: 2147483647 with ncurses extended functions support no: 20221231 without ncurses extended colors with postgres client integration without inotify support with kqueue support Darwin MacBookPro18 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar 6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000 arm64 $ pspg test.txt --log=log.log No data $ cat log.log Thu, 01 Feb 2024 18:57:49 +0100 [59149] started Thu, 01 Feb 2024 18:57:49 +0100 [59149] with utf8 support Thu, 01 Feb 2024 18:57:49 +0100 [59149] esc delay = -1 Thu, 01 Feb 2024 18:57:49 +0100 [59149] DataDesc is initialized Thu, 01 Feb 2024 18:57:49 +0100 [59149] sleep 10ms per 1000 rows Thu, 01 Feb 2024 18:57:49 +0100 [59149] cannot to read from file (Operation timed out) Thu, 01 Feb 2024 18:57:49 +0100 [59149] xterm mouse mode 1002 is not active Thu, 01 Feb 2024 18:57:49 +0100 [59149] No data Let me know if I can help somehow with debugging it.

looks so there is something wrong about detection eof, and because it fails on timeout, it shows a messy message. probably there will be some problem in _getline routine. Unfortunately, there is an "poll" function, and if I remember well, there are some issues related to this function on MacOS :-/ Maybe it has a different behavior than on other os. you can debug pspg - the most simply via gdb from other terminal or with writing to log - use function log_row(const char *fmt, ...) Regards Pavel

…

— Reply to this email directly, view it on GitHub <#237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEFO42JMRZEIK6QADXNDPLYRPJ3BAVCNFSM6AAAAABCVAXWCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRRHEYDGOJQHE> . You are receiving this because you commented.Message ID: ***@***.***>

[sasha-alias]

This line

			log_row("sleep 10ms per 1000 rows");
			usleep(1000 * 10);

For some reason the usleep causes the timeout. If I remove the usleep everything works fine.
Not sure what would be a proper fix though. Any ideas?

[okbob]

pá 2. 2. 2024 v 11:37 odesílatel Sasha Aliashkevich < ***@***.***> napsal:

This line <https://github.com/okbob/pspg/blob/master/src/table.c#L959> log_row("sleep 10ms per 1000 rows"); usleep(1000 * 10); For some reason the usleep causes the timeout. If I remove the usleep everything works fine. Not sure what would be a proper fix though. Any ideas?

<--><-->if ((f_data_opts & STREAM_HAS_NOTIFY_SUPPORT) && <--><--><--><-->nrows % 1000 == 0) <--><-->{ <--><--><-->log_row("sleep 10ms per 1000 rows"); <--><--><-->usleep(1000 * 10); <--><-->} It is strange, because macos has not NOTIFY support (I think) —

…

Reply to this email directly, view it on GitHub <#237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEFO434Y4F4RTHFSH77WSDYRS6YDAVCNFSM6AAAAABCVAXWCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRTGUZTIMRQGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[okbob]

pá 2. 2. 2024 v 12:53 odesílatel Pavel Stehule ***@***.***> napsal:

pá 2. 2. 2024 v 11:37 odesílatel Sasha Aliashkevich < ***@***.***> napsal: > This line <https://github.com/okbob/pspg/blob/master/src/table.c#L959> > > log_row("sleep 10ms per 1000 rows"); > usleep(1000 * 10); > > For some reason the usleep causes the timeout. If I remove the usleep > everything works fine. > Not sure what would be a proper fix though. Any ideas? > <--><-->if ((f_data_opts & STREAM_HAS_NOTIFY_SUPPORT) && <--><--><--><-->nrows % 1000 == 0) <--><-->{ <--><--><-->log_row("sleep 10ms per 1000 rows"); <--><--><-->usleep(1000 * 10); <--><-->} It is strange, because macos has not NOTIFY support (I think)

I am looking to code, and notify is ok. Looks so usleep is finished by some not processed state, and then breaks poll function. Maybe you can look what is in kquee after usleep. <--><-->struct kevent kqev; <--><-->struct timespec tmout = {0, 0}; <--><-->int><--><-->rc; <--><-->rc = kevent(notify_fd, NULL, 0, &kqev, 1, &tmout); <--><-->while (rc == 1) <--><--><-->rc = kevent(notify_fd, NULL, 0, &kqev, 1, &tmout); maybe usleep push some garbage there

…

— > Reply to this email directly, view it on GitHub > <#237 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAEFO434Y4F4RTHFSH77WSDYRS6YDAVCNFSM6AAAAABCVAXWCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRTGUZTIMRQGQ> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[okbob]

if you can, try to debug _getline function, you can compare it with linux.

[sasha-alias]

I added the following log straight after the _getline:

		read = _getline(&line, &len, f_data, f_data_opts & STREAM_IS_IN_NONBLOCKING_MODE, true);
		log_row("errno: %d, read: %zu", errno, read);

and got this:

...
Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6
Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6
Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6
Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6
Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6
Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 12
Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 1
Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 18446744073709551615
Sat, 03 Feb 2024 10:41:55 +0100 [10422] cannot to read from file (Operation timed out)
Sat, 03 Feb 2024 10:41:55 +0100 [10422] xterm mouse mode 1002 is not active
Sat, 03 Feb 2024 10:41:55 +0100 [10422] No data

I.e. at some point the errno starts to report 60 (ETIMEDOUT).
The file is read to the end though. But this code then exits because of the errno:

	if (errno && errno != EAGAIN)
	{
		log_row("cannot to read from file (%s)", strerror(errno));

		return false;
	}

If I ignore the ETIMEDOUT then things look working. If I remove usleep, then there is no ETIMEDOUT generated.
Not sure, maybe it's a Mac M1 chip specifics.

PS
kqueue looks empty after usleep.

[okbob]

so 3. 2. 2024 v 10:52 odesílatel Sasha Aliashkevich < ***@***.***> napsal:

I added the following log straight after the _getline: read = _getline(&line, &len, f_data, f_data_opts & STREAM_IS_IN_NONBLOCKING_MODE, true); log_row("errno: %d, read: %zu", errno, read); and got this: ... Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 12 Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 1 Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 18446744073709551615 Sat, 03 Feb 2024 10:41:55 +0100 [10422] cannot to read from file (Operation timed out) Sat, 03 Feb 2024 10:41:55 +0100 [10422] xterm mouse mode 1002 is not active Sat, 03 Feb 2024 10:41:55 +0100 [10422] No data I.e. at some point the errno starts to report 60 (ETIMEDOUT). The file is read to the end though. But this code then exits because of the errno: if (errno && errno != EAGAIN) { log_row("cannot to read from file (%s)", strerror(errno)); return false; } If I ignore the ETIMEDOUT then things look working. If I remove usleep, then there is no ETIMEDOUT generated. Not sure, maybe it's a Mac M1 chip specifics.

please, can you investigate when errno gets ETIMEDOUT? and what is result of usleep function?

…

PS kqueue looks empty after usleep. — Reply to this email directly, view it on GitHub <#237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEFO47EYUUT3PPZ2CDMMGDYRYCHJAVCNFSM6AAAAABCVAXWCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGI2TAMZSGM> . You are receiving this because you commented.Message ID: ***@***.***>

[okbob]

ne 4. 2. 2024 v 14:37 odesílatel Pavel Stehule ***@***.***> napsal:

so 3. 2. 2024 v 10:52 odesílatel Sasha Aliashkevich < ***@***.***> napsal: > I added the following log straight after the _getline: > > read = _getline(&line, &len, f_data, f_data_opts & STREAM_IS_IN_NONBLOCKING_MODE, true); > log_row("errno: %d, read: %zu", errno, read); > > and got this: > > ... > Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 > Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 > Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 > Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 > Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 > Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 12 > Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 1 > Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 18446744073709551615 > Sat, 03 Feb 2024 10:41:55 +0100 [10422] cannot to read from file (Operation timed out) > Sat, 03 Feb 2024 10:41:55 +0100 [10422] xterm mouse mode 1002 is not active > Sat, 03 Feb 2024 10:41:55 +0100 [10422] No data > > I.e. at some point the errno starts to report 60 (ETIMEDOUT). > The file is read to the end though. But this code then exits because of > the errno: > > if (errno && errno != EAGAIN) > { > log_row("cannot to read from file (%s)", strerror(errno)); > > return false; > } > > If I ignore the ETIMEDOUT then things look working. If I remove usleep, > then there is no ETIMEDOUT generated. > Not sure, maybe it's a Mac M1 chip specifics. > please, can you investigate when errno gets ETIMEDOUT? and what is result of usleep function?

it looks strange, because in poll function the timeout is not defined and usleep should not to raise ETIMEDOUT

…

> PS > kqueue looks empty after usleep. > > — > Reply to this email directly, view it on GitHub > <#237 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAEFO47EYUUT3PPZ2CDMMGDYRYCHJAVCNFSM6AAAAABCVAXWCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGI2TAMZSGM> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[okbob]

ne 4. 2. 2024 v 14:41 odesílatel Pavel Stehule ***@***.***> napsal:

ne 4. 2. 2024 v 14:37 odesílatel Pavel Stehule ***@***.***> napsal: > > > so 3. 2. 2024 v 10:52 odesílatel Sasha Aliashkevich < > ***@***.***> napsal: > >> I added the following log straight after the _getline: >> >> read = _getline(&line, &len, f_data, f_data_opts & STREAM_IS_IN_NONBLOCKING_MODE, true); >> log_row("errno: %d, read: %zu", errno, read); >> >> and got this: >> >> ... >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 12 >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 1 >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 18446744073709551615 >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] cannot to read from file (Operation timed out) >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] xterm mouse mode 1002 is not active >> Sat, 03 Feb 2024 10:41:55 +0100 [10422] No data >> >> I.e. at some point the errno starts to report 60 (ETIMEDOUT). >> The file is read to the end though. But this code then exits because of >> the errno: >> >> if (errno && errno != EAGAIN) >> { >> log_row("cannot to read from file (%s)", strerror(errno)); >> >> return false; >> } >> >> If I ignore the ETIMEDOUT then things look working. If I remove usleep, >> then there is no ETIMEDOUT generated. >> Not sure, maybe it's a Mac M1 chip specifics. >> > > please, can you investigate when errno gets ETIMEDOUT? > > and what is result of usleep function? > it looks strange, because in poll function the timeout is not defined and usleep should not to raise ETIMEDOUT

documentation for ETIMEDOUT is strange too 60 ETIMEDOUT *Operation* *timed* *out*. A connect or send request failed because the connected party did not properly respond after a period of time. (The timeout period is dependent on the communi-cation communication cation protocol.)

…

> > > > >> PS >> kqueue looks empty after usleep. >> >> — >> Reply to this email directly, view it on GitHub >> <#237 (comment)>, or >> unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AAEFO47EYUUT3PPZ2CDMMGDYRYCHJAVCNFSM6AAAAABCVAXWCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGI2TAMZSGM> >> . >> You are receiving this because you commented.Message ID: >> ***@***.***> >> >

[okbob]

ne 4. 2. 2024 v 14:55 odesílatel Pavel Stehule ***@***.***> napsal:

ne 4. 2. 2024 v 14:41 odesílatel Pavel Stehule ***@***.***> napsal: > > > ne 4. 2. 2024 v 14:37 odesílatel Pavel Stehule ***@***.***> > napsal: > >> >> >> so 3. 2. 2024 v 10:52 odesílatel Sasha Aliashkevich < >> ***@***.***> napsal: >> >>> I added the following log straight after the _getline: >>> >>> read = _getline(&line, &len, f_data, f_data_opts & STREAM_IS_IN_NONBLOCKING_MODE, true); >>> log_row("errno: %d, read: %zu", errno, read); >>> >>> and got this: >>> >>> ... >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 12 >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 1 >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 18446744073709551615 >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] cannot to read from file (Operation timed out) >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] xterm mouse mode 1002 is not active >>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] No data >>> >>> I.e. at some point the errno starts to report 60 (ETIMEDOUT). >>> The file is read to the end though. But this code then exits because of >>> the errno: >>> >>> if (errno && errno != EAGAIN) >>> { >>> log_row("cannot to read from file (%s)", strerror(errno)); >>> >>> return false; >>> } >>> >>> If I ignore the ETIMEDOUT then things look working. If I remove usleep, >>> then there is no ETIMEDOUT generated. >>> Not sure, maybe it's a Mac M1 chip specifics. >>> >> >> please, can you investigate when errno gets ETIMEDOUT? >> >> and what is result of usleep function? >> > > it looks strange, because in poll function the timeout is not defined and > usleep should not to raise ETIMEDOUT > > documentation for ETIMEDOUT is strange too 60 ETIMEDOUT *Operation* *timed* *out*. A connect or send request failed because the connected party did not properly respond after a period of time. (The timeout period is dependent on the communi-cation communication cation protocol.)

can you replace usleep by nanosleep? Can you check it?

…

> > >> >> >> >> >>> PS >>> kqueue looks empty after usleep. >>> >>> — >>> Reply to this email directly, view it on GitHub >>> <#237 (comment)>, or >>> unsubscribe >>> <https://github.com/notifications/unsubscribe-auth/AAEFO47EYUUT3PPZ2CDMMGDYRYCHJAVCNFSM6AAAAABCVAXWCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGI2TAMZSGM> >>> . >>> You are receiving this because you commented.Message ID: >>> ***@***.***> >>> >>

[okbob]

and maybe another strange hypothese https://stackoverflow.com/questions/48285535/macos-nanosleep-sleeping-for-far-too-long https://www.howtogeek.com/277414/what-is-app-nap-is-it-slowing-down-my-mac-apps/ ne 4. 2. 2024 v 15:09 odesílatel Pavel Stehule ***@***.***> napsal:

…

ne 4. 2. 2024 v 14:55 odesílatel Pavel Stehule ***@***.***> napsal: > > > ne 4. 2. 2024 v 14:41 odesílatel Pavel Stehule ***@***.***> > napsal: > >> >> >> ne 4. 2. 2024 v 14:37 odesílatel Pavel Stehule ***@***.***> >> napsal: >> >>> >>> >>> so 3. 2. 2024 v 10:52 odesílatel Sasha Aliashkevich < >>> ***@***.***> napsal: >>> >>>> I added the following log straight after the _getline: >>>> >>>> read = _getline(&line, &len, f_data, f_data_opts & STREAM_IS_IN_NONBLOCKING_MODE, true); >>>> log_row("errno: %d, read: %zu", errno, read); >>>> >>>> and got this: >>>> >>>> ... >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 0, read: 6 >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 6 >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 12 >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 1 >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] errno: 60, read: 18446744073709551615 >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] cannot to read from file (Operation timed out) >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] xterm mouse mode 1002 is not active >>>> Sat, 03 Feb 2024 10:41:55 +0100 [10422] No data >>>> >>>> I.e. at some point the errno starts to report 60 (ETIMEDOUT). >>>> The file is read to the end though. But this code then exits because >>>> of the errno: >>>> >>>> if (errno && errno != EAGAIN) >>>> { >>>> log_row("cannot to read from file (%s)", strerror(errno)); >>>> >>>> return false; >>>> } >>>> >>>> If I ignore the ETIMEDOUT then things look working. If I remove >>>> usleep, then there is no ETIMEDOUT generated. >>>> Not sure, maybe it's a Mac M1 chip specifics. >>>> >>> >>> please, can you investigate when errno gets ETIMEDOUT? >>> >>> and what is result of usleep function? >>> >> >> it looks strange, because in poll function the timeout is not defined >> and usleep should not to raise ETIMEDOUT >> >> > documentation for ETIMEDOUT is strange too > > 60 ETIMEDOUT *Operation* *timed* *out*. A connect or send request failed > because the connected party did not properly respond after a > period of time. (The timeout period is dependent on the communi-cation communication > cation protocol.) > > > can you replace usleep by nanosleep? Can you check it? > > >> >> >>> >>> >>> >>> >>>> PS >>>> kqueue looks empty after usleep. >>>> >>>> — >>>> Reply to this email directly, view it on GitHub >>>> <#237 (comment)>, >>>> or unsubscribe >>>> <https://github.com/notifications/unsubscribe-auth/AAEFO47EYUUT3PPZ2CDMMGDYRYCHJAVCNFSM6AAAAABCVAXWCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGI2TAMZSGM> >>>> . >>>> You are receiving this because you commented.Message ID: >>>> ***@***.***> >>>> >>>

[okbob]

I cannot to reproduce it.