moonbitlang / async / 1085
78%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 161
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 77.043% (+0.06%) from 76.981%
1085

push

github

web-flow 
Runtime fixes: stdio shared file position, spawn orphan on pidfd_open failure, ws2_32 linkage (#573)

* fix(stdio): use the shared file position for regular-file stdio channels

`setup_stdio` gave a regular-file stdio channel a private write offset
starting at 0, turning every write into a positioned `pwrite`. A stdio
channel's file description is shared with the parent and possibly with
sibling processes, so this had three wrong consequences for any async
MoonBit program whose stdout/stderr is redirected to a file:

- output written by an earlier process (or the parent) at the same
  descriptor was overwritten from position 0;
- a descriptor opened in append mode was not appended to, because
  `pwrite` bypasses `O_APPEND`;
- the inherited file position was ignored.

Use position `-1` instead — the plain read/write path that append-mode
files from `open()` already use — so the OS-maintained shared position
and `O_APPEND`/`FILE_APPEND_DATA` semantics apply, as they do for
ordinary processes. Reading stdin from a regular file follows the same
rule.

Found by the `@shell` package's redirect tests, which run a MoonBit
test program with `AppendToFile` and observed it overwriting instead.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X6uYtEdLugFjzsqN2vQKex

* fix(event_loop): do not orphan a spawned child when pidfd_open fails

After a successful `posix_spawn`, a `pidfd_open` failure other than
`ENOSYS`/`EPERM` — `EMFILE` under descriptor pressure being the
realistic one — was converted into a spawn error. The child was already
running: the caller never received its PID, so it escaped its task
group unkilled and was never reaped. Leave the handle invalid instead;
`wait_pid` already falls back to a blocking `waitpid` in a worker
thread when there is no pidfd, and `free_spawn_job` only closes valid
handles.

Also parenthesize the intended `ENOSYS`/`EPERM` test in
`open_pid_handle`, which previously al... (continued)

3799 of 4931 relevant lines covered (77.04%)

11959.72 hits per line

Coverage Regressions

Lines Coverage ∆ File
1
83.33
 -4.17% src/tls/transport.mbt
Jobs
ID Job ID Ran Files Coverage
1 1085.1 161
77.04
 GitHub Action Run
Source Files on build 1085