Maybe this case should be an error (and hence raise an exception on the Python side)? Because if you ask to wait for the lock and don't get it... that's unexpected.

As far as I know, this occurs whenever a thread attempts to wait on a lock that it already owns: https://github.com/freebsd/freebsd-src/blob/62c1865c9aaef436498c444b460e6ec2fbcaf44d/sys/kern/kern_lock.c#L614 (and https://github.com/freebsd/freebsd-src/blob/62c1865c9aaef436498c444b460e6ec2fbcaf44d/sys/kern/kern_lockf.c#L893 although there are more instances in that file).

However I see that mutexes are initialised with PTHREAD_MUTEX_RECURSIVE so, assuming this flag is actually taken into account, my only guess is that the way threads are handled in MicroPython triggers a potential cycle in FreeBSD's lock graph. One may assume that it's a transient situation, hence the aliasing that to Linux's EBUSY case (or possibly treat it as if it returned EAGAIN).

Removing this particular bit may also require more changes since EDEADLK isn't part of py/mperrno.h and has to be added there to handle the situation cleanly in the affected tests. My main concern with this is that EDEADLK on Linux comes from pthreads, so in theory it may not be there. Also, I'm not entirely sure if aliasing EDEADLK to EAGAIN at the errno level is the correct thing to do w.r.t. threads since on non-Linux EAGAIN may mean something slightly different in other cases.

I just installed FreeBSD 15.0-RELEASE-p9 in a VM, and built the unix port (standard variant) from master (ie not this PR) with clang (I disabled BTREE, FFI, SSL options). It runs the tests/threads/thread_coop.py test just fine, whereas the commit message here says the EDEADLK code is needed to pass that test.

All the thread tests pass for me on master, except the two you noted: thread_heap_lock.py and thread_lock5.py. And they fail exactly due to raising EDEADLK! Those tests do test the main thread re-acquiring a lock, but a separate thread is supposed to release it. Maybe FreeBSD doesn't support this use case?? Although that would be very surprising.

There's something here that needs fixing. The thread_heap_lock.py and thread_lock5.py tests are giving a big clue, and ideally we would get them passing.

OK, so mutexes associated with _thread.allocate_lock() are not initialize recursively. So that's why FreeBSD is returning EDEADLK, because the thread tries to acquire it a second time (in those two tests that fail).

This works OK on Linux (at least) but obviously not FreeBSD's implementation of pthreads.

Making it recursive won't work, it's supposed to block the main thread ("deadlock" it actually) until another thread releases the lock.

Maybe we need to use semaphores instead to implement thread.allocate_lock.

I'd be surprised too if releasing a mutex from a different thread isn't possible on FreeBSD.

I wish I remember which patch level I used when drafting this PR, but I'm quite sure thread_coop.py failed on me because EDEADLK was returned, I seem to recall it happened when the two threads' execution models were swapped. It could have been that it took longer than expected to shutdown the thread on FreeBSD, but given the situation a retry condition made sense.

Still, yes, there's more to look at! I'll re-create the VM and look at this too. Thanks for trying this out on your end as well.

OK, mystery solved! Here's the relevant part of CPython's _thread implementation (Python/thread_pthread.h):

/* A pthread mutex isn't sufficient to model the Python lock type
 * because, according to Draft 5 of the docs (P1003.4a/D5), both of the
 * following are undefined:
 *  -> a thread tries to lock a mutex it already has locked
 *  -> a thread tries to unlock a mutex locked by a different thread
 * pthread mutexes are designed for serializing threads over short pieces
 * of code anyway, so wouldn't be an appropriate implementation of
 * Python's locks regardless.
 *
 * The pthread_lock struct implements a Python lock as a "locked?" bit
 * and a <condition, mutex> pair.  In general, if the bit can be acquired
 * instantly, it is, else the pair is used to block the thread until the
 * bit is cleared.     9 May 1994 tim@ksr.com
 */

typedef struct {
    char             locked; /* 0=unlocked, 1=locked */
    /* a <cond, mutex> pair to handle an acquire of a locked lock */
    pthread_cond_t   lock_released;
    pthread_mutex_t  mut;
} pthread_lock;

Interesting. Looks like the situation is specified to be ambiguous too! From https://pubs.opengroup.org/onlinepubs/007908799/xsh/pthread_mutex_lock.html:

If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex maintains the concept of a lock count. When a thread successfully acquires a mutex for the first time, the lock count is set to one. Every time a thread relocks this mutex, the lock count is incremented by one. Each time the thread unlocks the mutex, the lock count is decremented by one. When the lock count reaches zero, the mutex becomes available for other threads to acquire. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error will be returned.
[...]
The pthread_mutex_lock() function may fail if:

[EDEADLK]
The current thread already owns the mutex.
[...]
The pthread_mutex_unlock() function may fail if:

[EPERM]
The current thread does not own the mutex.

So, recursive mutexes are specified but may not work, and threads may or may not unlock other threads' mutexes...

It's quite a bit of refactoring to fix this properly.

For this PR I suggest just undo the changes to this file and accept the thread test failures under FreeBSD for now.

Done. I've updated tests/extmod/select_poll_fd.py as well.

Having the sys module is a requirement for a port to be able to run the tests, but sys.platform can be missing.

If a port has the select and errno modules then it's highly likely it has sys.platform. So I suggest putting the check after the import of select/errno, and just access sys.platform without any try/except, like this:

if sys.platform == "freebsd":
    print("SKIP")
    raise SystemExit

Turns out sys may not be there, after all. This test is also checked against CPython, which fails with an import error (eg. https://github.com/micropython/micropython/actions/runs/27251624169/job/80477170312?pr=18979).

Ah, sorry, I meant that a port is required to implement the sys module (I didn't mean that sys will already be imported).

Anyway, what you have here is good!