On Thu, Dec 8, 2016 at 10:01 AM, 'rean' via OSv Development < [email protected]> wrote:
> Signed-off-by: rean <[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]. > 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.
