In D44101#1006654, @olce wrote:

It seems that a stub was exposed by libc up to 0db2fac06ab70163, unless this is an artifact of the svn or git import.

Further code archeology indeed seems to support what you say.

That is technically true. It was exposed by abd529cebab9018d0fa9b328cdaaab3a51d87b44 so it was exposed for nearly 15 minutes. :)

In D44101#1006654, @olce wrote:

Today, its implementation performs (almost) the same as the POSIX-specified sched_yield(), which should be used instead.

It is quite different from sched_yield(). yield() tries to keep thread off cpu as much as possible, while sched_yield() re-schedules immediately.

So in fact I am not sure what to do about it:

solo% rg SYS_YIELD                                              ~/work/build/go
src/syscall/zsysnum_freebsd_amd64.go
180:    SYS_YIELD                    = 321 // { int yield(void); }

In D44101#1006727, @kib wrote:

So in fact I am not sure what to do about it:

solo% rg SYS_YIELD                                              ~/work/build/go
src/syscall/zsysnum_freebsd_amd64.go
180:    SYS_YIELD                    = 321 // { int yield(void); }

Code search shows this and some unrelated Rust definitions for Redox OS. This seems to be a simple translation of our system call table. If there are users of this enum they aren't in public code.

In D44101#1006744, @brooks wrote:

In D44101#1006727, @kib wrote:

So in fact I am not sure what to do about it:

solo% rg SYS_YIELD                                              ~/work/build/go
src/syscall/zsysnum_freebsd_amd64.go
180:    SYS_YIELD                    = 321 // { int yield(void); }

Code search shows this and some unrelated Rust definitions for Redox OS. This seems to be a simple translation of our system call table. If there are users of this enum they aren't in public code.

I vote to keep the syscall, even without the libsys stub.

In D44101#1006706, @kib wrote:

In D44101#1006654, @olce wrote:

Today, its implementation performs (almost) the same as the POSIX-specified sched_yield(), which should be used instead.

It is quite different from sched_yield(). yield() tries to keep thread off cpu as much as possible, while sched_yield() re-schedules immediately.

Yes, that is the intent of setting priority to PRI_MAX_TIMESHARE, for timesharing processes only. I thought this wouldn't work because as soon as sched_add() is called, the user priority is recomputed, hence the "(almost)" above, but it's true it currently isn't set in td_priority before sleeping, contradicting some comments. This is a scheduler mechanism I'm reworking.

I don't think this syscall is used anywhere, the references you found are just part of FFI implementations. It is not present on Linux. It's present in NetBSD, where it is a strict alias to sched_yield(). It's also present on OpenBSD, with (almost, in a different sense) the same meaning as sched_yield() (the latter has a refinement to allow other threads of the same process to run first).

The precise functionality is quite dependent on the scheduler implementation.

I'm fine either way (keeping it or removing it). If we keep it, it would probably be better to change its name (to something like yield_to_all()).

In D44101#1006672, @brooks wrote:

That is technically true. It was exposed by abd529cebab9018d0fa9b328cdaaab3a51d87b44 so it was exposed for nearly 15 minutes. :)

Ah... Should have continued my archeology in this direction then... :)

In D44101#1006848, @olce wrote:

It's present in NetBSD, where it is a strict alias to sched_yield(). It's also present on OpenBSD, with (almost, in a different sense) the same meaning as sched_yield() (the latter has a refinement to allow other threads of the same process to run first).

In fact, no, there, yield() is not exported and for kernel usage only.