[Bug libc/28730] Extend posix_spawnattr_* interface with more useful features
adhemerval.zanella at linaro dot org
sourceware-bugzilla@sourceware.org
Mon Jan 10 14:54:42 GMT 2022
https://sourceware.org/bugzilla/show_bug.cgi?id=28730
--- Comment #6 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Cristian Rodríguez from comment #5)
> So the best way way would be to use the pad space to introduce a an internal
> opaque struct which we can modify or extend at will ? even with all
> implementation-defined leisure we still shouldn't break the ABI..
Yes, although I would first use the current space available and keep space for
a pointer to allow extend the functionaly. Something like:
typedef struct
{
short int __flags;
pid_t __pgrp;
sigset_t __sd;
sigset_t __ss;
struct sched_param __sp;
int __policy;
/* Add newer fields here. */
int __pad[N];
void *__reserved/
} posix_spawnattr_t;
So for posix_spawnattr_setpdeathsig_np it would be something like:
typedef struct
{
short int __flags;
pid_t __pgrp;
sigset_t __sd;
sigset_t __ss;
struct sched_param __sp;
int __policy;
int __deathsignal;
int __pad[M];
} posix_spawnattr_t;
With M adjusted to keep the current size. For posix_spawnattr_setrlimit_np I
would do:
typedef struct
{
short int __flags;
pid_t __pgrp;
sigset_t __sd;
sigset_t __ss;
struct sched_param __sp;
int __policy;
int __deathsignal;
void *__resource;
int __pad[M];
} posix_spawnattr_t;
And internally '__resource' will be array of:
struct posix_spawn_resource
{
int resource;
struct rlimit64 rlim;
}
(The rlimit has the LFS issue, so I think it shold be supported only for LFS
mode).
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Glibc-bugs
mailing list