> incompatible in macOS due to a recent update

Can you elaborate on this a bit? How has a recent update made forking 
incompatible on MacOS?

Tom

> On 23 Mar 2020, at 19:22, Ahmad A. Hussein <ahmadahusse...@gmail.com> wrote:
> 
> Django's parallel test runner works through forking processes, making it 
> incompatible on Windows by default and incompatible in macOS due to a recent 
> update. Windows and macOS both support spawn and have it enabled by default. 
> Databases are cloned for each worker.
> 
> To switch from fork to spawn, state setup will be handled by spawned 
> processes instead of through inheritance via fork. Worker’s connections to 
> databases can still be done through get_test_db_clone_settings which changes 
> the names of databases assigned to a specific worker_id; however, SQLite's 
> cloning method is incompatible with spawn.  
> 
> 
> SQLite’s cloning method relies on it both being in-memory and fork as when we 
> fork the main process, we retain SQLite's in-memory database in the child 
> process. The solution is to get a SQL dump of the database and throw it into 
> the target cloned databases. This is also the established standard in 
> handling MySQL’s cloning process.
> 
> Both Postgresql's and MySQL's cloning methods are independent of fork or 
> spawn and won't require any modification.
> 
> Oracle has not been implemented in the parallel test runner originally even 
> on Linux and I propose to extend support to Oracle as well in my proposal. I 
> want to confirm if there is significant support behind this as a feature or 
> not before I commit to writing a specification, but as a summary it is 
> definitely possible as the work collaborated on by Aymeric Augustin and Shai 
> Berger show that cloning CAN be done through multiple ideas. The reason why 
> it's a headache is that Oracle does not support separate databases under a 
> single user- unlike our other supported databases, so we can't clone 
> databases without introducing another user. Some methods may also need to be 
> rewritten to accommodate for the Oracle backend, but that isn't an issue.
> 
> I've glossed over writing out a schedule or a more detailed abstract as I I'm 
> mainly posting here to see if there is indeed support for the Oracle proposal 
> and to make sure I am not missing any details in regards to adapting the 
> current parallel test runner to work through spawn. Let me know what you 
> think.
> 
> Regards,
> Ahmad
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/317f67c6-4b23-483f-ada5-9bdbb45d0997%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/317f67c6-4b23-483f-ada5-9bdbb45d0997%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/322804F5-F44F-4EF8-AF33-C460EC509915%40tomforb.es.

Reply via email to