| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
@vstinner @serhiy-storchaka Please, review and once we are happy with the interface and implementation we can add new tests for the flags in this PR. |
Sorry, something went wrong.
|
This implementation is missing setting the POSIX_SPAWN_SETSCHEDPARAM flag implementation because I am not sure what is the best way to actually implement the interface to set the scheduler parameters unsing posix_spawnattr_setschedparam. Any ideas? |
Sorry, something went wrong.
|
@gpshead @serhiy-storchaka I have implemented the existing flags as keyword-only arguments as suggested in the issue. The question of what to do with POSIX_SPAWN_SETSCHEDPARAM remains. |
Sorry, something went wrong.
There was a problem hiding this comment.
Notice that in case that non of the flags are set the attr object is still created (with no flags or arguments set). This is to avoid wrapping these lines in
if ((setpgroup != Py_None) | (resetids != Py_True) | (setsigmask != Py_None)
| (setsigdef != Py_None) | (setscheduller != Py_None) ) {
...
}
As far as I understand there is no different between this and passing NULL to posix_spawn.
Sorry, something went wrong.
There was a problem hiding this comment.
Notice that this same function exists in Modules/signalmodule.c but is private (static). I did not want to export that symbol in libpython so I recreated the function here. Please, advise if you think a header/extern declaration should be created and the function should be exported (in this case we will need to name it properly).
Sorry, something went wrong.
There was a problem hiding this comment.
This is fine. A future refactoring can combine these if ever desired (and if both extension modules are statically linked, a good linker would merge them as being identical anyways).
Sorry, something went wrong.
There was a problem hiding this comment.
though I see Serhiy diagreeing, follow his lead.
Sorry, something went wrong.
|
Please regenerate the clinic file. |
Sorry, something went wrong.
|
@serhiy-storchaka I had to rebase onto the latest master to pick up the latest changes and solve the merge conflict of the clinic file. I have done that and regenerated it. |
Sorry, something went wrong.
|
Please merge with the master again and regenerate the clinic file. |
Sorry, something went wrong.
| with self.assertRaises(TypeError): | ||
| posix.posix_spawn(sys.executable, | ||
| [sys.executable, "-c", "pass"], | ||
| os.environ, resetids=0) |
There was a problem hiding this comment.
What's the rationale for rejecting 0 as false? resetids=0 seems legit to me.
Why not using "bool" type for this parameter? Something like:
@@ -5416,7 +5411,7 @@ os.posix_spawn
*
setpgroup: object = NULL
The pgroup to use with the POSIX_SPAWN_SETPGROUP flag.
- resetids: object = False
+ resetids: bool = False
If the value is `True` the POSIX_SPAWN_RESETIDS will be activated.
setsigmask: object(c_default='NULL') = ()
The sigmask to use with the POSIX_SPAWN_SETSIGMASK flag.
Sorry, something went wrong.
There was a problem hiding this comment.
If we use bool then the truthiness value of the object will be used. This will allow the user to pass anything there (ant the boolean value of the argument will be used), right?
I would prefer to pass only True or False (maybe 0 and 1 as well) but not any object.
Sorry, something went wrong.
| with self.assertRaises(ValueError): | ||
| posix.posix_spawn(sys.executable, | ||
| [sys.executable, "-c", "pass"], | ||
| os.environ, setsigmask=[9998, 9999]) |
There was a problem hiding this comment.
I would prefer a more explicit signal.NSIG rather than arbitrary integer 9999. Maybe [signal.NSIG, signal.NSIG+1]?
Sorry, something went wrong.
|
|
||
| pid2, status = os.waitpid(pid, 0) | ||
| self.assertEqual(pid2, pid) | ||
| self.assertNotEqual(status, 0) |
There was a problem hiding this comment.
I would suggest a stricter test:
self.assertTrue(os.WIFSIGNALED(status), status)
self.assertEqual(os.WTERMSIG(status), signal.SIGUSR1)
Sorry, something went wrong.
There was a problem hiding this comment.
done
Sorry, something went wrong.
|
When you're done making the requested changes, leave the comment: I have made the requested changes; please review again. |
Sorry, something went wrong.
|
The overall change LGTM, but I have a few questions/suggestions. |
Sorry, something went wrong.
|
|
||
|
|
||
| .. function:: posix_spawn(path, argv, env, file_actions=None) | ||
| .. function:: posix_spawn(path, argv, env, file_actions=None, /, *, \ |
There was a problem hiding this comment.
I don't believe this / should be here.
Sorry, something went wrong.
There was a problem hiding this comment.
See #6725.
Sorry, something went wrong.
|
I have made the requested changes; please review again |
Sorry, something went wrong.
|
Thanks for making the requested changes! @vstinner, @serhiy-storchaka: please review the changes made to this pull request. |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM.
Sorry, something went wrong.
|
Yeah! It's now time to see how to use it in subprocess :-) |
Sorry, something went wrong.
|
I don't see a use case for it in the stdlib. |
Sorry, something went wrong.
|
I am not talking about the new flags, but more generally, I would like to
see if using posix_spawn() rather than _posixsubprocess would make
subprocess faster. Yes, according to earlier Pablo's benchmarks.
|
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
https://bugs.python.org/issue20104