That's fair.

I'll look into a more appropriate OSv-specific implementations for these
functions.

Thanks,
Rean

On Thursday, December 8, 2016, Nadav Har'El <[email protected]> wrote:

>
> On Thu, Dec 8, 2016 at 10:01 AM, 'rean' via OSv Development <
> [email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
>
>> Signed-off-by: rean <[email protected]
>> <javascript:_e(%7B%7D,'cvml','[email protected]');>>
>> ---
>>  Makefile        |  1 +
>>  libc/pthread.cc | 20 ++++++++++++++++++++
>>  libc/pthread.hh |  6 ++++++
>>  3 files changed, 27 insertions(+)
>>
>> diff --git a/Makefile b/Makefile
>> index 9182618..1995882 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1653,6 +1653,7 @@ libc += unistd/getppid.o
>>  libc += unistd/getsid.o
>>  libc += unistd/setsid.o
>>
>> +musl += unistd/ttyname_r.o
>>
>
> Thanks. I guess there is no harm, per se, of using this musl
> implementation.
> However, looking at what it actually does, it will try to readlink()
> /proc/fd/*. And since OSv doesn't actually support that (yet...), the
> function will simply fail with a ENOENT. This is not even one of the errors
> that ttyname() is supposed to return.
>
> I wonder if we shouldn't have a more OSv-specific stub of ttyname_r (and
> ttyname): Since OSv does not currently support any form of virtual
> terminals or ptys, we could perhaps have a stub that returns, if
> isatty(fd), the fixed pathname "/dev/console".
>
>
>>  musl += regex/fnmatch.o
>>  musl += regex/glob.o
>>  musl += regex/regcomp.o
>> diff --git a/libc/pthread.cc b/libc/pthread.cc
>> index 148b79e..508fdbe 100644
>> --- a/libc/pthread.cc
>> +++ b/libc/pthread.cc
>> @@ -1121,3 +1121,23 @@ int pthread_attr_getaffinity_np(const
>> pthread_attr_t *attr, size_t cpusetsize,
>>
>>      return 0;
>>  }
>> +
>> +int pthread_barrier_init(pthread_barrier_t *__restrict b,
>> +                         const pthread_barrierattr_t *__restrict a,
>> +                         unsigned count)
>> +{
>> +   WARN_STUBBED();
>> +   return 0;
>> +}
>> +
>> +int pthread_barrier_destroy(pthread_barrier_t *)
>> +{
>> +   WARN_STUBBED();
>> +   return 0;
>> +}
>> +
>> +int pthread_barrier_wait(pthread_barrier_t *)
>> +{
>> +   WARN_STUBBED();
>>
> +   return 0;
>>
>
> Stubs are useful for functions that applications often expect (and can
> live with) an error, so we can return an error. Alternatively, sometimes we
> can stub a function to pretend to succeed because we expect applications to
> use this function but then never actually care if this function worked or
> not.
>
> In this case, I'm worried - if the application actually uses
> pthread_barrier_wait() it probably assumes it worked correctly, namely it
> waited, and one thread returned PTHREAD_BARRIER_SERIAL_THREAD and the rest
> return zero... I don't see how returning 0 for all threads and doing this
> immediately could be a sensible replacement for that?
>
> I think it shouldn't be hard to write a correct implementation here, based
> on existing primitives - namely mutex and condition_variable.
> I also see we have include/osv/latch.hh something which I think (?)
> resembles pthread_barrier in purpose - maybe we could reuse that, or write
> code that is similar to that code.
>
>
>> +}
>> diff --git a/libc/pthread.hh b/libc/pthread.hh
>> index 1a4d02c..c76addc 100644
>> --- a/libc/pthread.hh
>> +++ b/libc/pthread.hh
>> @@ -26,4 +26,10 @@ void run_tsd_dtors();
>>  }
>>  #endif
>>
>> +int pthread_barrier_init(pthread_barrier_t *__restrict,
>> +                         const pthread_barrierattr_t *__restrict,
>> +                         unsigned);
>> +int pthread_barrier_destroy(pthread_barrier_t *);
>> +int pthread_barrier_wait(pthread_barrier_t *);
>> +
>>  #endif /* PTHREAD_HH_ */
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected]
>> <javascript:_e(%7B%7D,'cvml','osv-dev%[email protected]');>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to