Writes to stdin pipe of a process can write less bytes than requested, but still report `SDL_IO_STATUS_READY`

[HolyBlackCat]

This happens on both Windows and Linux.

If I create a process with SDL_PROP_PROCESS_CREATE_STDIN_NUMBER = SDL_PROCESS_STDIO_APP and try to write more than 64k bytes at once (that's the number on Linux, it's smaller on Windows), then SDL_WriteIO() will return a smaller value than the specified length (64k on Linux), but SDL_GetIOStatus() still reports SDL_IO_STATUS_READY. I've tested this on cat on Linux, and a similar custom program on Windows.

I don't mind this behavior per se, but I suggest documenting it (I could make a PR if needed).

Alternatively, SDL could retry the writes (for remaining bytes) automatically. Is there any downside to doing that?

[icculus]

This is because we're setting these to be non-blocking, but I doubt SDL_IOFromFD expects that.

static bool SetupStream(SDL_Process *process, int fd, const char *mode, const char *property)
{
    // Set the file descriptor to non-blocking mode
    fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK);

    SDL_IOStream *io = SDL_IOFromFD(fd, true);

Do we want these to be non-blocking?

[HolyBlackCat]

I think them being non-blocking is good. Blocking on a process pipe can easily deadlock if the process waits for IO on another pipe, so you need to constantly poke all pipes you have in a loop until the process finishes.

[slouken]

Do we want these to be non-blocking?

Yes, this is intentional for the reasons @HolyBlackCat mentioned.

[icculus]

Okay, fair enough.

Here's the plan, then: on a short read/write from the POSIX stdio backend (what SDL_IOFromFD uses), we'll try to read/write the difference. If it reports -1 (error) or 0 (EOF), we'll set the correct IoStatus. If it reads/writes everything that was remaining, we'll call it READY, and if it reads/writes short again (or returned -1 with errno=EAGAIN), we'll call it NOT_READY.

Feels a little messy, but it satisfies the existing docs, which say short writes can always figure out what went wrong with SDL_GetIOStatus(). It would be cleaner (for SDL) to have a short write return READY and let the next call report errors, but more annoying for the app, not to mention change behavior unnecessarily.

[HolyBlackCat]

Hm, but why only one retry? What if the write is long enough to require 3+ tries?

[icculus]

If you'd like us to wait for the write to complete, we should just not make the file handle non-blocking. :)

Trying a second time is just to get a result from the system call, which won't report an error (or EOF on reads) if it was able to move some data the first time. If it then reports EAGAIN or makes it only a little further, we can report it as SDL_IO_STATUS_NOT_READY.

[icculus]

Okay, this should work as advertised now (and testprocess shows it handling short writes correctly, as it tries to write a megabyte to a child process). Let me know if this is still causing you problems!