A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-February/097535.html below:

[Python-Dev] Forking and Multithreading - enemy brothers

[Python-Dev] Forking and Multithreading - enemy brothers [Python-Dev] Forking and Multithreading - enemy brothersPascal Chambon chambon.pascal at gmail.com
Tue Feb 9 20:42:50 CET 2010
Hello

Some update about the spawnl() thingy ;

I've adapted the win32 code to have a new unix Popen object, which works 
with a spawn() semantic. It's quite straightforward, and the 
mutiprocessing call of a python functions works OK.

But I've run into some trouble : synchronization primitives.
Win32 semaphore can be "teleported" to another process via the 
DuplicateHandle() call. But unix named semaphores don't work that way - 
instead, they must be opened with the same name by each spawned subprocess.
The problem here, the current semaphore C code is optimized to forbid 
semaphore sharing (other than via fork) : use of (O_EXL|O_CREAT) on 
opening, immediate unlinking of new semaphores....

So if we want to benefit from sync primitives with this spawn() 
implementation, we need a working named semaphore implementation, too...

What's the best in your opinion ? Editing the current multiprocessing 
semaphore's behaviour to allow (with specific options, attributes and 
methods) its use in this case ? Or adding a new NamedSemaphore type like 
this one ?
http://semanchuk.com/philip/posix_ipc/

Regards,
Pascal

>
>
>

More information about the Python-Dev mailing list

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