[David Ascher]
> I noticed that the support for the semaphore calls in the various thread_*
> is very very spotty, with a comment in the BeOS implementation that read:
>
> * Guido says not to implement this because it's not used anywhere;
> * I'll do it anyway, you never know when it might be handy, and it's
> * easy...
> (that last bit is not true of all implementations, apparently =).
>
> 1) Is it true that the sema_ calls are never used?
Best I can tell, the following sema functions are indeed never used:
PyThread_allocate_sema
PyThread_free_sema
PyThread_down_sema
PyThread_up_sema
the following #define's are never used:
WAIT_SEMA
NOWAIT_SEMA
and the following non-sema pythread.h functions are not only never used,
they're defined only in thread_sgi.h:
PyThread_create_key
PyThread_delete_key
PyThread_set_key_value
PyThread_get_key_value
> 2) If yes, shouldn't we remove the sema_ calls from the thread
> API and have similar functionality on all platforms?
+1 from me. If someone wants platform-specific thread functions, they
should be in a platform-specific extension module, not messing up the core.
> (There are related issues re: for example whether async thread locking is
> available, whether threads are joinable or not (see
> thread_cthread.h), etc.)
Sorry, don't know what you're getting at here (e.g., have any specific line
or function of thread_cthread.h in mind?).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4