Author serhiy.storchaka
Recipients John Jones, alex, benjamin.peterson, dhduvall, gennad, gregory.p.smith, martin.panter, miss-islington, ned.deily, neologix, pablogsal, serhiy.storchaka, vstinner
Date 2018-05-14.15:44:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1526312698.07.0.682650639539.issue20104@psf.upfronthosting.co.za>
In-reply-to
Content
As for the scheduler interface, yet one option is using two mutually exclusive parameters setschedparam and setscheduler. The first take a sched_param, the second takes a pair: int and sched_param. This will not simplify the implementation, but they directly correspond to functions os.sched_setparam() and os.sched_setscheduler(). I don't say that this interface is better than alternatives, I just mention yet one option.

posix_spawn() can be easily implemented via fork()/exec(). See the reference implementation: http://pubs.opengroup.org/onlinepubs/009695399/xrat/xsh_chap03.html . It can be directly translated to Python. Seems the only value of posix_spawn() is on systems that don't provide fork()/exec(), but provide posix_spawn(). Is posix_spawn() supported on Windows? What are other systems supported by Python that don't provide fork()/exec()?

I'm for removing os.posix_spawn() in 3.7. Even if we will accept the current interface and merge PR 6693 we can find other problems with the interface or the implementation. And os.posix_spawnp() still is not implemented. It is just too dangerous to add such complex feature between the last beta and RC.
History
Date User Action Args
2018-05-14 15:44:58serhiy.storchakasetrecipients: + serhiy.storchaka, gregory.p.smith, vstinner, benjamin.peterson, ned.deily, alex, dhduvall, neologix, gennad, martin.panter, John Jones, pablogsal, miss-islington
2018-05-14 15:44:58serhiy.storchakasetmessageid: <1526312698.07.0.682650639539.issue20104@psf.upfronthosting.co.za>
2018-05-14 15:44:58serhiy.storchakalinkissue20104 messages
2018-05-14 15:44:57serhiy.storchakacreate