On Sat, Apr 23, 2016 at 02:58:16AM +0200, Kamil Rytarowski wrote:
> Alternatively adding support for pthread_getcpuclockid() + using
> clock_gettime(3) would approximate the result (as it's done for Linux
> and FreeBSD).
That is a lot cleaner, though the Posix description of
pthread_getcpuclockid
In article <20160423124132.gc2...@mail.duskware.de>,
Martin Husemann wrote:
>On Sat, Apr 23, 2016 at 02:58:16AM +0200, Kamil Rytarowski wrote:
>> Alternatively adding support for pthread_getcpuclockid() + using
>> clock_gettime(3) would approximate the result (as it's done for Linux
>> and FreeBS
On Sat, Apr 23, 2016 at 12:53:15PM +, Christos Zoulas wrote:
> >That is a lot cleaner, though the Posix description of
> >pthread_getcpuclockid is not explaining the semantics of that clock (or
> >I am overlooking it?)
>
> This is not hard to do...
Yes but I was wondering if the "cpu" in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23.04.2016 15:01, Martin Husemann wrote:
> On Sat, Apr 23, 2016 at 12:53:15PM +, Christos Zoulas wrote:
>>> That is a lot cleaner, though the Posix description of
>>> pthread_getcpuclockid is not explaining the semantics of that
>>> clock (or
On Sat, Apr 23, 2016 at 03:17:40PM +0200, Kamil Rytarowski wrote:
> The pthread_getcpuclockid() function shall return in clock_id the
> clock ID of the CPU-time clock of the thread specified by thread_id,
> if the thread specified by thread_id exists.
And what does "the CPU-time clock" mean?
Mart
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23.04.2016 15:19, Martin Husemann wrote:
> On Sat, Apr 23, 2016 at 03:17:40PM +0200, Kamil Rytarowski wrote:
>> The pthread_getcpuclockid() function shall return in clock_id
>> the clock ID of the CPU-time clock of the thread specified by
>> threa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The sem_open(2) function call reports an error for a too long name and
sets errno:
[ENAMETOOLONG] The name argument is too long.
I noted in the kernel that the limit is SEM_MAX_NAMELEN:
do_ksem_open(struct lwp *l, const char *semname, int ofla
On Sat, Apr 23, 2016 at 06:06:10PM +0200, Kamil Rytarowski wrote:
> The sem_open(2) function call reports an error for a too long name and
> sets errno:
>
> [ENAMETOOLONG] The name argument is too long.
...as it should.
> The limit is held privately in the kernel:
>
> sys/kern/uipc_s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23.04.2016 20:55, David Holland wrote:
> On Sat, Apr 23, 2016 at 06:06:10PM +0200, Kamil Rytarowski wrote:
>> The sem_open(2) function call reports an error for a too long
>> name and sets errno:
>>
>> [ENAMETOOLONG] The name argument is too
On Sat, Apr 23, 2016 at 10:42:52PM +0200, Kamil Rytarowski wrote:
> >> I read in the POSIX resources that the limit is defined by
> >> PATH_MAX or its variation:
> >>
> >> ENAMETOOLONG The length of the name argument exceeds {PATH_MAX}
> >> or a pathname component is longer than {NAME_MAX}.
On Sat, Apr 23, 2016 at 09:12:43PM +, David Holland wrote:
> > >> Additionally I noted that SEM_VALUE_MAX is defined at least twice
> > >> in the code-base, in and sys/kern/uipc_sem.c
> > >> (thankfully with the same value: ~0U).
> > >
> > > That would be a bug.
>
> namely: pleas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23.04.2016 23:52, David Holland wrote:
> On Sat, Apr 23, 2016 at 09:12:43PM +, David Holland wrote:
> Additionally I noted that SEM_VALUE_MAX is defined at least
> twice in the code-base, in and
> sys/kern/uipc_sem.c (thankfully w
12 matches
Mail list logo
