pil21: Why do waitFd and gPoll use 292MY for timeout?
I am trying to fix infinite select errors about 292MY.
src/lib.c:
int32_t gPoll(struct pollfd *fds, int32_t nfds, int64_t timeout) {
if (timeout == 9223372036854775807) { // 292MY
int i = nfds;
do
if (--i < 0)
return 0;
while (fds[i].fd < 0);
}
return (int32_t)poll(fds, (nfds_t)nfds, (int)timeout);
}
On my mac (int)9223372036854775807 == -1 which means no timeout. Why not
simply use -1?
src/io.l:
(de i64 waitFd (Exe (i32 . Fd) (i64 . Ms))
...
(and
(gt0 Ms)
(lt0 (dec 'Ms Dif))
(setq Ms 0) )
(setq Tim Now) )
... )
When Ms decrement to 9223372036854775806, (int)timeout becomes -2 which is
less than -1, then poll() returns EINVAL.
In the meantime I found two compile warnings:
src/lib.c: warning: use of GNU ?: conditional expression extension
ffi *ffiPrep(char *lib, char *fun, int64_t lst) {
if (ffi_prep_cif(&p->cif, FFI_DEFAULT_ABI, nargs, rtype, p->args)
== FFI_OK &&
(p->fun = dlsym(lib ?: RTLD_DEFAULT, fun)) )
src/lib.c: warning: '&' within '|' [-Wbitwise-op-parentheses]
int readyOut(struct pollfd *p) {
if (p->fd < 0)
return 0;
p->fd = -1;
return (p->revents & POLLOUT | POLLERR | POLLNVAL) != 0;
}
Please have a look. Thanks!
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi all, I just stumbled across this mail in the archive. I have not received it, and the sending e-mail address seems just "picolisp". > picolisp Sun, 11 Apr 2021 15:05:25 -0700 > > I am trying to fix infinite select errors about 292MY. > > On my mac (int)9223372036854775807 == -1 which means no timeout. This is strange! The number 292MY is the biggest *positive* 64-bit number. A call to waitFd() is compiled to e.g.: call i64 @waitFd(i64 %0, i32 -1, i64 9223372036854775807) Does this mean the Mac uses only the lowest 32 bits? Also, -1 does *not* mean "no timeout". It means infinite timeout. > Why not simply use -1? This would not work, because waitFd() compares the value to all other timeouts in the task list. So it needs a big positive number. > When Ms decrement to 9223372036854775806, (int)timeout becomes -2 which is > less > than -1, then poll() returns EINVAL. This is equally strange! The man page of poll() says "Specifying a negative value in timeout means an infinite timeout". -2 or any other negative number does no harm. > src/lib.c: warning: '&' within '|' [-Wbitwise-op-parentheses] I hate compilers treating me like a child! ;) In summary, the problem seems to be that 'int's on the Mac are only 32 bit. But that would break many other things, no? Any other Mac users here? I thought pil21 runs on the Mac (?). ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
On Thu, Apr 15, 2021 at 07:46:35AM +0200, Alexander Burger wrote: > Hi all, > > I just stumbled across this mail in the archive. I have not received it, and > the > sending e-mail address seems just "picolisp". > > > picolisp Sun, 11 Apr 2021 15:05:25 -0700 Ah, that's all right! There is indeed a registered list member with that name :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi, Yes, ‘int’ is 32bit on macOS, even when compiling to 64bit. The pil21 demoApp does not work on macOS. pahihu sizeof(char) = 1 sizeof(short) = 2 sizeof(int) = 4 sizeof(long) = 8 sizeof(long long) = 8 sizeof(float) = 4 sizeof(double) = 8 sizeof(long double) = 16 sizeof(void*) = 8 > On 2021. Apr 15., at 7:46, Alexander Burger wrote: > > In summary, the problem seems to be that 'int's on the Mac are only 32 bit. > But > that would break many other things, no? Any other Mac users here? I thought > pil21 runs on the Mac (?). > > ☺/ A!ex
Re: Why do waitFd and gPoll use 292MY for timeout?
On Thu, Apr 15, 2021 at 08:07:21AM +0200, Andras Pahi wrote: > Hi, > > Yes, ‘int’ is 32bit on macOS, even when compiling to 64bit. > The pil21 demoApp does not work on macOS. Thanks Andras! That's too bad! If poll(2) uses only 32 bits for the timeout, the maximum is 49 days (as opposed to the 292 million years (292MY) in 64 bits). — Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
On Thu, Apr 15, 2021 at 08:32:32AM +0200, Alexander Burger wrote: > That's too bad! If poll(2) uses only 32 bits for the timeout, the maximum is > 49 > days (as opposed to the 292 million years (292MY) in 64 bits). Not even that! For signed 32 bits it is only 24 days :( Should I change the design of waitFd() to use only 32 bits? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
On Thu, Apr 15, 2021 at 08:42:04AM +0200, Alexander Burger wrote:
> Should I change the design of waitFd() to use only 32 bits?
Looks like I should do that.
poll(2) is badly specified, using only int for the timeout. But we have to live
with that, there may be other ABIs (other BSDs?) which define 'int' as 32 bits.
So I could change waitFd() to use -1 internally if a maximal value of 24 days is
passed. This would mean that all relevant Lisp-level functions ('wait', 'sync',
'key' and readline input) may wait forever.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote: > Looks like I should do that. Done! Can somebody test on a Macintosh or other BSDs? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
> On Thu, Apr 15, 2021 at 08:32:32AM +0200, Alexander Burger wrote: >> That's too bad! If poll(2) uses only 32 bits for the timeout, the maximum is >> 49 >> days (as opposed to the 292 million years (292MY) in 64 bits). > > Not even that! For signed 32 bits it is only 24 days :( > > Should I change the design of waitFd() to use only 32 bits? > > âº/ A!ex A workaround is to poll ceil(N/(2^32)) times. By the way what happens when (timeout > 292MY)? > The man page of poll() says "Specifying a negative value in timeout means an > infinite timeout". -2 or any other negative number does no harm. The OSX man page is different. Yes, only -1 means infinite timeout. I'm also trying to fix the parser/repl but that would be on another thread. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi, I grabbed the latest pil21.tgz and demoApp.tgz. "pil @lib/test.l +" runs without errors. On macOS I've got /pil app/main.l -ap~main -'go 4040' + 6538 = 58885 48782252818959702~ ap: !? (wait Ms T "Sd") Select error: Invalid argument ap? Select error: Invalid argument ap? Select error: Invalid argument … ap? Select error: Invalid argument ap? Segmentation fault: 11 It has the same behavior as the previous version of pil21. Regards, Andras Pahi > On 2021. Apr 15., at 12:51, Alexander Burger wrote: > > On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote: >> Looks like I should do that. > > Done! > > Can somebody test on a Macintosh or other BSDs? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Andras, > > /pil app/main.l -ap~main -'go 4040' + > 6538 = 58885 48782252818959702~ > ap: !? (wait Ms T "Sd") > Select error: Invalid argument > ... > It has the same behavior as the previous version of pil21. Yeah, I thought about it, and came to the conclusion that today's change in gPoll() is only relevant for very large (> 24 days) timeouts. Such a timeout is seldom used, I think. So what causes the above error? It happens in 'listen' (line 94 in @lib/net.l): (de listen (Sd Ms) (loop (NIL (wait Ms T Sd)) (T (accept Sd) @) ) ) "Select error" is issued by poll(). But which argument is ivalid? Can you try to trace or debug? Is the socket descriptor invalid? The 'Ms' argument must be NIL cause listen is called by 'server' as (listen P). Thus 'wait' passes 292MY to waitFd(). Any idea? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Andras, https://webirc.envs.net/uploads/5d228d2686705b27/8AB6ED6B-5EAC-4CBC-BCF8-84BB26447763.jpeg this is my try on latest big sur April 15, 2021 7:53 PM, "Andras Pahi" wrote: > Hi, > > I grabbed the latest pil21.tgz and demoApp.tgz. > > "pil @lib/test.l +" runs without errors. > > On macOS I've got > > ./pil app/main.l -ap~main -'go 4040' + > > 6538 = 58885 48782252818959702~ > > ap: !? (wait Ms T "Sd") > > Select error: Invalid argument > > ap? Select error: Invalid argument > > ap? Select error: Invalid argument > > … > ap? Select error: Invalid argument > ap? Segmentation fault: 11 > > It has the same behavior as the previous version of pil21. > > Regards, > Andras Pahi > >> On 2021. Apr 15., at 12:51, Alexander Burger wrote: >> On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote: >>> Looks like I should do that. >> >> Done! >> >> Can somebody test on a Macintosh or other BSDs? >> >> ☺/ A!ex >> >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Mike, Thank you for the test, I am still on Mojave. I will check my setup where it went wrong. Regards, Andras > On 2021. Apr 15., at 21:13, Mike wrote: > > Andras, > > https://webirc.envs.net/uploads/5d228d2686705b27/8AB6ED6B-5EAC-4CBC-BCF8-84BB26447763.jpeg > this is my try on latest big sur > > > > April 15, 2021 7:53 PM, "Andras Pahi" wrote: > >> Hi, >> >> I grabbed the latest pil21.tgz and demoApp.tgz. >> >> "pil @lib/test.l +" runs without errors. >> >> On macOS I've got >> >> ./pil app/main.l -ap~main -'go 4040' + >> >> 6538 = 58885 48782252818959702~ >> >> ap: !? (wait Ms T "Sd") >> >> Select error: Invalid argument >> >> ap? Select error: Invalid argument >> >> ap? Select error: Invalid argument >> >> … >> ap? Select error: Invalid argument >> ap? Segmentation fault: 11 >> >> It has the same behavior as the previous version of pil21. >> >> Regards, >> Andras Pahi >> >>> On 2021. Apr 15., at 12:51, Alexander Burger wrote: >>> On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote: Looks like I should do that. >>> >>> Done! >>> >>> Can somebody test on a Macintosh or other BSDs? >>> >>> ☺/ A!ex >>> >>> -- >>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Alex, Thank you for your suggestions, I have traced listen and wait and both have The parameters are as expected (Ms is NIL, Sd is 17). As Mike tested on macOS Big Sur and it worked, the problem is in my setup. Regards, Andras > On 2021. Apr 15., at 19:11, Alexander Burger wrote: > > Hi Andras, > >> >> /pil app/main.l -ap~main -'go 4040' + >> 6538 = 58885 48782252818959702~ >> ap: !? (wait Ms T "Sd") >> Select error: Invalid argument >> ... >> It has the same behavior as the previous version of pil21. > > Yeah, I thought about it, and came to the conclusion that today's change in > gPoll() is only relevant for very large (> 24 days) timeouts. Such a timeout > is > seldom used, I think. > > So what causes the above error? > > It happens in 'listen' (line 94 in @lib/net.l): > > (de listen (Sd Ms) > (loop > (NIL (wait Ms T Sd)) > (T (accept Sd) @) ) ) > > "Select error" is issued by poll(). But which argument is ivalid? > > Can you try to trace or debug? > > Is the socket descriptor invalid? The 'Ms' argument must be NIL cause listen > is > called by 'server' as (listen P). Thus 'wait' passes 292MY to waitFd(). > > Any idea? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
$ picolisp -wait [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775807] [fds=0x0][nfds=0][timeout=9223372036854775806] !? (wait) Select error: Invalid argument ? : (wait) !? (wait) Select error: Invalid argument ? : (wait) !? (wait) Select error: Invalid argument ? fds was NULL, but then became non-NULL. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi, It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout values which when casted to (int) results in values less than -1 (eg. -3). This results in EINVAL errors in poll(). I have inserted a code snippet which truncates the timeout to -1 then I can get to the login page in the demo app. Entering eg. “ben”, “ben” results in dropping the connection. The task handling the connection is forked, as I see in the process list. Any ideas how to get further ? Thanks, Andras Pahi > On 2021. Apr 16., at 7:43, Andras Pahi wrote: > > Hi Alex, > > Thank you for your suggestions, I have traced listen and wait and both have > The parameters are as expected (Ms is NIL, Sd is 17). > > As Mike tested on macOS Big Sur and it worked, the problem is in my setup. > > Regards, > Andras > >> On 2021. Apr 15., at 19:11, Alexander Burger wrote: >> >> Hi Andras, >> >>> >>> /pil app/main.l -ap~main -'go 4040' + >>> 6538 = 58885 48782252818959702~ >>> ap: !? (wait Ms T "Sd") >>> Select error: Invalid argument >>> ... >>> It has the same behavior as the previous version of pil21. >> >> Yeah, I thought about it, and came to the conclusion that today's change in >> gPoll() is only relevant for very large (> 24 days) timeouts. Such a timeout >> is >> seldom used, I think. >> >> So what causes the above error? >> >> It happens in 'listen' (line 94 in @lib/net.l): >> >> (de listen (Sd Ms) >> (loop >>(NIL (wait Ms T Sd)) >>(T (accept Sd) @) ) ) >> >> "Select error" is issued by poll(). But which argument is ivalid? >> >> Can you try to trace or debug? >> >> Is the socket descriptor invalid? The 'Ms' argument must be NIL cause listen >> is >> called by 'server' as (listen P). Thus 'wait' passes 292MY to waitFd(). >> >> Any idea? >> >> ☺/ A!ex >> >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Andras, > It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout > values which when casted to (int) results in values less than -1 (eg. -3). > This results in EINVAL errors in poll(). The EINVAL is indeed strange. According to the man page any negative timout should result in an infinite wait. > I have inserted a code snippet which truncates the timeout to -1 then I can > get > to the login page in the demo app. This should not be necessary since PicoLip 21.4.15. It checks at compile time whether it is a system with 32-bit int's, and then passes -1 for larger numbers: #if (int)-1 == 0x else if (timeout > 2147483647) // Fit into 32 bits (max 24 days) timeout = -1; #endif I cannot test it here. Can you verify that it works? > Entering eg. “ben”, “ben” results in dropping the connection. The task > handling the connection > is forked, as I see in the process list. Hmm, so the above is not enough. There must be some other problem, perhaps also related to 32-bit integers. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Alex,
Thank you for looking after this.
According to the man page on macOS, poll returns:
[EINVAL] The nfds argument is greater than OPEN_MAX or the
timeout argument is less than -1.
The check at compile time is not triggered on macOS, the following program
prints “false”:
#include
#include
int main(int argc, char*argv[])
{
#if (int)-1 == 0x
printf("true");
#else
printf("false");
#endif
return 0;
}
Regards,
Andras Pahi
> On 2021. Apr 17., at 11:42, Alexander Burger wrote:
>
> Hi Andras,
>
>> It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout
>> values which when casted to (int) results in values less than -1 (eg. -3).
>> This results in EINVAL errors in poll().
>
> The EINVAL is indeed strange. According to the man page any negative timout
> should result in an infinite wait.
>
>
>> I have inserted a code snippet which truncates the timeout to -1 then I can
>> get
>> to the login page in the demo app.
>
> This should not be necessary since PicoLip 21.4.15. It checks at compile time
> whether it is a system with 32-bit int's, and then passes -1 for larger
> numbers:
>
> #if (int)-1 == 0x
> else if (timeout > 2147483647) // Fit into 32 bits (max 24 days)
> timeout = -1;
> #endif
>
> I cannot test it here. Can you verify that it works?
>
>
>> Entering eg. “ben”, “ben” results in dropping the connection. The task
>> handling the connection
>> is forked, as I see in the process list.
>
> Hmm, so the above is not enough. There must be some other problem, perhaps
> also
> related to 32-bit integers.
>
> ☺/ A!ex
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Andras,
> According to the man page on macOS, poll returns:
>
> [EINVAL] The nfds argument is greater than OPEN_MAX or the
> timeout argument is less than -1.
That explains it! So the specification of poll() is indeed different from the
Linux one.
> The check at compile time is not triggered on macOS, the following program
> prints “false”:
>
> #include
> #include
>
> int main(int argc, char*argv[])
> {
> #if (int)-1 == 0x
> printf("true");
> #else
> printf("false");
> #endif
> return 0;
Hmm, too bad! I tested here with 64-bit integers with
#if (int)-1 == 0x
and it worked.
Unfortunately, "#if sizeof(int) == 4" is not allowed in C, that's why I used the
above construct.
Does anybody have a better idea?
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Alex, Maybe the definition of #define __INT_MAX__ 2147483647 could be used ? It is predefined by the clang/gcc preprocessor. Regards, Andras Pahi > On 2021. Apr 17., at 13:02, Alexander Burger wrote: > Unfortunately, "#if sizeof(int) == 4" is not allowed in C, that's why I used > the > above construct. > > Does anybody have a better idea? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi all, On Sat, Apr 17, 2021 at 01:02:20PM +0200, Alexander Burger wrote: > Hmm, too bad! I tested here with 64-bit integers with > >#if (int)-1 == 0x > > and it worked. Uuhh! Sorry! I was completely off the track! 'int' is *always* 32 bit in size, on every system I've seen so far! How could I forget and confuse this? So the whole concept of 292MY in pil21 is nonsense. It never worked, because poll() would never wake up for timeouts greater than 24.86 days. It seems I never ran a test with such a timeout ;) Anyway, I will fix pil21. .. but this does not explain the MacOS problems ... ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Andras, > Maybe the definition of > > #define __INT_MAX__ 2147483647 > > could be used ? It is predefined by the clang/gcc preprocessor. Yeah, should be portable enough. But as you saw in my last mail, the whole question is obsolete. I have to adjust pil21 anyway. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
On Sat, Apr 17, 2021 at 02:15:42PM +0200, Alexander Burger wrote: > But as you saw in my last mail, the whole question is obsolete. I have to > adjust > pil21 anyway. I will use ppoll(2). ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Alex, Just one remark, ppoll(2) is Linux-specific. I know there is a perfectly portable API - Linux. Regards, Andras Pahi > On 2021. Apr 17., at 15:53, Alexander Burger wrote: > > On Sat, Apr 17, 2021 at 02:15:42PM +0200, Alexander Burger wrote: >> But as you saw in my last mail, the whole question is obsolete. I have to >> adjust >> pil21 anyway. > > I will use ppoll(2). > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Andras, > Just one remark, ppoll(2) is Linux-specific. Oh, you are right! Too bad, it would have been a perfect replacement! Good that you mention this, I did not pay attention. > I know there is a perfectly portable API - Linux. Yes :) Hmm, I'm just testing the ppoll() version ... What to do? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
On Sat, Apr 17, 2021 at 04:21:53PM +0200, Alexander Burger wrote: > Hmm, I'm just testing the ppoll() version ... What to do? OK, as ppoll() works fine on Linux (tests passed), I will keep it. This covers most use cases, including Servers (Debian), PilBox (Android) and smaller stuff (Raspi). I put an #ifdef for other systems, using poll() and setting infinite timeout above 24 days. BTW, the problems on MacOS are not explained with this. Even more as we now know that on Linux too the 64 bit timeout was truncated to 32 bits. And I think nowhere (e.g. demo app) such a big timeout was passed so that the value wrapped to negative. Something else must be seriously wrong. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
On Sat, Apr 17, 2021 at 04:35:09PM +0200, Alexander Burger wrote: > OK, as ppoll() works fine on Linux (tests passed), I will keep it. This covers > most use cases, including Servers (Debian), PilBox (Android) and smaller stuff > (Raspi). > > I put an #ifdef for other systems, using poll() and setting infinite timeout > above 24 days. Done!! Released a new pil21.tgz :) @Andras: Can you test on Mac again? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Alex, Perfect, it works as expected on macOS. Finally I’ve got demoApp working: the culprit was the Safari browser. With Firefox it works! Regards, Andras Pahi > On 2021. Apr 17., at 16:54, Alexander Burger wrote: > > On Sat, Apr 17, 2021 at 04:35:09PM +0200, Alexander Burger wrote: >> OK, as ppoll() works fine on Linux (tests passed), I will keep it. This >> covers >> most use cases, including Servers (Debian), PilBox (Android) and smaller >> stuff >> (Raspi). >> >> I put an #ifdef for other systems, using poll() and setting infinite timeout >> above 24 days. > > Done!! Released a new pil21.tgz :) > > @Andras: Can you test on Mac again? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Why do waitFd and gPoll use 292MY for timeout?
Hi Andras, > Perfect, it works as expected on macOS. Great! :) > Finally I’ve got demoApp working: the culprit was the Safari browser. > With Firefox it works! I see. But then the Pil GUI must somehow be faulty too. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
