Add non-blocking io mode setter for POSIX

[quantimnot]

No description provided.

[quantimnot]

Don't merge yet.

I'm writing a more comprehensive test that includes setting/unsetting the mode and exception handling.

[quantimnot]

@elcritch
Does freertos have non-blocking io support?
From the CI results, I think it has fcntl and O_NONBLOCK, but my test case hangs, which is what it would do if the stdin fd wasn't non-blocking.

[quantimnot]

If I'm looking at the correct code here: https://github.com/FreeRTOS/FreeRTOS/blob/40c9e37d109fbfaa1e1940a97a600309bc6bd72a/FreeRTOS/Demo/Common/ethernet/lwip-1.4.0/src/api/sockets.c
then FreeRTOS fcntl impl is only concerned with sockets.

But if that is the case, why isn't the call returning a -1 value and then raising an exception?

Maybe each platform for FreeRTOS defines fcntl and their implementations return 0?
I don't know. I'm disabling the test for FreeRTOS.

[quantimnot]

I want to disable the test for FreeRTOS, but Testament isn't working when I spec: disabled: "freertos".

I made #19137 to change that in Testament. Waiting on that.

[elcritch]

Does freertos have non-blocking io support?
From the CI results, I think it has fcntl and O_NONBLOCK, but my test case hangs, which is what it would do if the stdin fd wasn't non-blocking.

It's not clear to me that it does. Or if it does that it'll work via POSIX. Also the tests for FreeRTOS were just meant for compile time checks as to properly test it'd need a QEMU setup.

[elcritch]

But if that is the case, why isn't the call returning a -1 value and then raising an exception?

Maybe each platform for FreeRTOS defines fcntl and their implementations return 0? I don't know. I'm disabling the test for FreeRTOS.

That seems fair. The fcntl for on the RTOS'es don't always behave as expected by POSIX. Sometimes they accept a value but ignore it. Other times it can depend on whether you have another module compiled in.

Is O_NONBLOCK primarily for non-IP sockets?

[quantimnot]

@elcritch

tests for FreeRTOS were just meant for compile time checks

Ok, maybe some other platform was hanging. It wasn't very clear to me.

Is O_NONBLOCK primarily for non-IP sockets?

I'm not sure, but I think it is for any fd type that can block, like pipes and sockets.

[quantimnot]

I don't see what's failing. Something about 'tests/vm/tslow_tables.nim c' timing out, but I don't see that in the logs. I'm not familiar with Azure Pipelines.

I ran the code on a Linux machine. It is hanging because the child proc isn't exiting or the io selector isn't signalling that it exited. I'll debug that when I get a chance over the next few days.

[elcritch]

@quantimnot FYI there's a "View more details on Azure Pipelines" on the Azure pipelines logs that'll let you dive into the full error details.

[dom96]

Define for Windows too, but with a {.error: ....} (less confusing than getting a "Undeclared identifier" error

[elcritch]

@quantimnot did you ever get this figured out? I'm up for helping figure out any of the RTOS conflicts.

[quantimnot]

@elcritch Thank you for the offer to help. I've been away a few weeks while I've focused on some important matters.

I don't see any reasonable way to handle different RTOS ports having varying levels of POSIX compatibility, other than a build configuration phase that tests for compatibility and then sets a define flag. I could wrap the interface in a when defined hasPosixFcntl block, but we don't do that with any of the other POSIX interfaces, so that would be very inconsistent.

The current hangup with this PR is the test I made. A bug is making it hang on Linux. I haven't fixed it yet, because I got distracted on a POSIX FFI library that I've been experimenting with. I will get back to this as soon as I can.

I also want to change the interface after I have chatted with alaviss: alaviss/nim-sys#29

[elcritch]

Reading through the PR, I think you could pretty readily keep the network and file logic separate at the cost of duplicating a few lines of code.

It seems like you could add these bits to setNonBlocking in native sockets:

when SupportIoctlInheritCtl:
  if c_ioctl(f, FIONBIO, unsafeAddr(opt)) == -1:

Then when SupportIoctlInheritCtl isn't defined the RTOS'es will try and execute the normal POSIX path. They should ignore it it's not available, or error out. Either no need to special RTOS handling at this point. Any RTOS tests currently should only compile the test, not run it.

[elcritch]

Looking up FIONBIO I'm confused if using it is an improvement over the O_NONBLOCK? It's a bit of a weird corner but this stackoverflow makes it sound like O_NONBLOCK is more recent/more standard.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.

[github-actions]

This pull request is stale because it has been open for 1 year with no activity. Contribute more commits on the pull request and rebase it on the latest devel, or it will be closed in 30 days. Thank you for your contributions.

[github-actions]

This pull request has been marked as stale and closed due to inactivity after 395 days.