[Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD

[Łukasz Langa]

Wiadomość napisana przez Martin v. Löwis w dniu 2010-12-30, o godz. 10:16:

> Am 30.12.2010 04:45, schrieb Brian Quinlan:
> 
>> So skipping the test is probably the way to go.
> 
> I'm still -1 on that proposal.

I agree with Martin, explanation follows.

In general, I'm trying to think as the user: someone wrote a program and said it requires Python 3.2. I expect it to work on Python 3.2 available on my platform. Doesn't matter if it's bundled with the OS or custom built.

When a module is not available, this should fail loudly and as fast as possible. This is currently the case with conditionally built modules like curses, sqlite3, tkinter and others. From the user's perspective: the import fails. From the administrator's perspective: the build reports skipped modules. The admin can then alter the environment to make the build behave as expected, and then run the tests to confirm it works. From an OS maintainer perspective it's even better: a module can be made available optionally with explicitly set dependencies and required configuration.

In our specific case a bunch of things should be determined first:
1. Does it still fail on FreeBSD 7.3+?
2. Why is the semaphore limit so low in the first place?
3. What is a reasonable number for that limit? That should include situations where people run multiple applications.
4. What other configuration should be done to ensure the module won't break on runtime.

Some answers Philip gave already. Knowing all these things would let us decide whether switching the module off on systems that don't meet the requirements is okay and can we get away with just documenting how to make it work. One problem is that the administrator can make the OS compatible/incompatible on runtime (with sysctl).

ISTM concurrent.futures was included a bit too early in the distribution. The module has problems not only on BSD [1]. Fortunately, there is visible action from Brian, Philip and David to make the problems go away. I'm sure it will be fixed pretty soon. Ultimately I also agree with Martin that an implementation using SysV IPC would probably be better from the user's perspective. As he said, even if the underlying code is not as pretty as with the POSIX APIs, once it's written and tested nobody cares because it's not exposed. However, it's far too late to change that now for 3.2.

[1] On RedHat/CentOS the test freezes badly (issue 10517).

-- 
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101230/f04c45cf/attachment.html>