Bug 245773 - lang/python3: Missing errno.EDEADLOCK
Summary: lang/python3: Missing errno.EDEADLOCK
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-python (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-20 19:45 UTC by stefan.witzel
Modified: 2021-09-16 13:14 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (python)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description stefan.witzel 2020-04-20 19:45:23 UTC
In the Python module errno the constant errno.EDEADLOCK is missing. According to the Python documentation EDEADLOCK is part of the module.

The problem occurs when a process on a remote host runnning an OS as Linux returns EDEADLOCK.  (I know EDEADLOCK is not Posix compatible and the Linux documentations says and it's synonym for EDEADLK, but Python allows to use it.)

I think a mapping from EDEADLOCK to EDEADLK would be sufficent to solve the problem.
Comment 1 Gleb Popov freebsd_committer 2021-09-16 12:25:54 UTC
What is the problem, exactly? I don't believe you can send error codes from one machine to another and expect them to match.

On FreeBSD just use errno.EDEADLK
Comment 2 Willem Jan Withagen 2021-09-16 12:43:38 UTC
(In reply to Gleb Popov from comment #1)

Yes you are corect. And even on Linux `man 3 errno` tells:
```
       EDEADLOCK
              On most architectures, a synonym for EDEADLK.  On some
              architectures (e.g., Linux MIPS, PowerPC, SPARC), it is a
              separate error code "File locking deadlock error".
```
and in the errno file itself:
```
asm-generic/errno.h:#define     EDEADLK         35      /* Resource deadlock would occur */
asm-generic/errno.h:#define     EDEADLOCK       EDEADLK
```

But it would be a lot more conveinient if it did exist and worked as expected.

The problem of the requestor is not fixed with this, since on FreeBSD `EDEADLK` has value 11, so things will not work as expected.
And sending error codes between FreeBSD and Linux will require translation for more than just this one.

Then again Python claims that it errno.EDEADLOCK is there, so we should atleast fix that omission.
Comment 3 Gleb Popov freebsd_committer 2021-09-16 12:54:00 UTC
(In reply to Willem Jan Withagen from comment #2)

> But it would be a lot more conveinient if it did exist and worked as expected.

And what's expected in this case? I, for example, expect an undefined constant, because FreeBSD doesn't have EDEADLOCK code.

> Then again Python claims that it errno.EDEADLOCK is there,

Actually, at the top of https://docs.python.org/3/library/errno.html there is a following sentence:

> Of the following list, symbols that are not used on the current platform are not defined by the module. The specific list of defined symbols is available as errno.errorcode.keys().

I think there is no bug here. At least, no FreeBSD-specific one. If the reporter believes that EDEADLOCK should be automatically mapped to something, the right thing is to open a PR on the Python bug tracker.
Comment 4 Willem Jan Withagen 2021-09-16 13:11:19 UTC
(In reply to Gleb Popov from comment #3)
>> But it would be a lot more conveinient if it did exist and worked as expected.

> And what's expected in this case? I, for example, expect an undefined constant, because FreeBSD doesn't have EDEADLOCK code.

On FreeBSD I would errno.EDEADLOCK to be 11....

Like I said, that does not fix the problem of the submitter.

We can call it whatever we want, but fixing this will cause less python code to crash on first execution, where then the user dives into the python code and does something to handle the lack of.
Be it comment it out, if-def-ignore or whatever.

And yes you are probably correct in suggestiing that this might have a better place at the python code itself.
(Not to speak of getting it in cython)
Comment 5 Gleb Popov freebsd_committer 2021-09-16 13:14:23 UTC
I will close this PR, then. Stefan, if you want this to be fixed, try contacting upstream.