You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Rainer Jung <ra...@kippdata.de> on 2023/03/16 13:00:27 UTC
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Hello Ivan,
Am 21.01.23 um 17:13 schrieb ivan@apache.org:
> Author: ivan
> Date: Sat Jan 21 16:13:27 2023
> New Revision: 1906889
>
> URL: http://svn.apache.org/viewvc?rev=1906889&view=rev
> Log:
> Merge thread-name branch (PR 60587) [1]:
> * Introduce apr_thread_name_set() and apr_thread_name_get().
>
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60587
> [2] https://lists.apache.org/thread/z24logzc6v8tc0p2q3375cc10qo9y5yw
>
> Modified:
> apr/apr/trunk/ (props changed)
> apr/apr/trunk/build/apr_threads.m4
> apr/apr/trunk/configure.in
> apr/apr/trunk/include/apr_thread_proc.h
> apr/apr/trunk/include/arch/win32/apr_arch_misc.h
> apr/apr/trunk/test/testthread.c
> apr/apr/trunk/threadproc/beos/thread.c
> apr/apr/trunk/threadproc/netware/thread.c
> apr/apr/trunk/threadproc/os2/thread.c
> apr/apr/trunk/threadproc/unix/thread.c
> apr/apr/trunk/threadproc/win32/thread.c
>
> Propchange: apr/apr/trunk/
> ------------------------------------------------------------------------------
> Merged /apr/apr/branches/thread-name:r1902296-1906888
>
> Modified: apr/apr/trunk/build/apr_threads.m4
> URL: http://svn.apache.org/viewvc/apr/apr/trunk/build/apr_threads.m4?rev=1906889&r1=1906888&r2=1906889&view=diff
> ==============================================================================
> --- apr/apr/trunk/build/apr_threads.m4 (original)
> +++ apr/apr/trunk/build/apr_threads.m4 Sat Jan 21 16:13:27 2023
> @@ -312,3 +312,27 @@ elif test "$apr_cv_mutex_robust_shared"
> [Define if non-posix/portable cross-process robust mutexes are available])
> fi
> ])
> +
> +
> +dnl Check for pthread_setname_np
> +dnl Note: Only detects two-arg version
> +AC_DEFUN([APR_CHECK_PTHREAD_SETNAME_NP], [
> +AC_CACHE_CHECK([for pthread_setname_np support],
> +[apr_cv_pthread_setname_np], [
> +AC_TRY_COMPILE([
> +#include <pthread.h>
> +],[
> +pthread_t td = pthread_self();
> +pthread_setname_np(td, "name");
> +],[
> + apr_cv_pthread_setname_np=yes
> +],[
> + apr_cv_pthread_setname_np=no
> +])])
> +
> +if test "$apr_cv_pthread_setname_np" = "yes"; then
> + AC_DEFINE([HAVE_PTHREAD_SETNAME_NP], 1,
> + [Define if pthread_setname_np is available])
> +fi
> +])dnl
> +
Thsi configure check does *not* fail for me on SLES 11 where
pthread_[gs]ername_np is not available. In config.log I find
warning: implicit declaration of function ‘pthread_setname_np’
but configure procees with a "yes". The buidl then succeeds, but the
library is not usable due to the unresolvable symbol.
Best regards,
Rainer
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Ruediger Pluem <rp...@apache.org>.
On 3/17/23 11:20 AM, Rainer Jung wrote:
> Thanks Yann, configure now detects the missing function.
>
> But: testpoll fails:
>
> testpoll : Line 897: apr_pollset_poll() didn't sleep
>
> Unfortunately I don't know when it started. Any idea, what I should investigate?
>
> All this is on SLES11, haven't tried the recent APR trunk with newer Linuxes, but r1908005 worked on them including testpoll tests.
testpoll still works fine on RedHat 7 and RedHat 8 64 bit for me.
Regards
Rüdiger
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Rainer Jung <ra...@kippdata.de>.
Am 21.03.23 um 16:46 schrieb Yann Ylavic:
> On Tue, Mar 21, 2023 at 2:24 PM Yann Ylavic <yl...@gmail.com> wrote:
>>
>> Is there something I can #ifdef (or check at configure/run time) for
>> SLELS11 or the kernel? This would document in the test that a minimal
>> timeout is usually expected, but on this platform/kernel. Or I'll use
>> 190ms for everyone, which looks "unfair".
>
> Does r1908616 work for you?
Thanks again, yes that works.
>> Regards;
>> Yann.
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Mar 21, 2023 at 2:24 PM Yann Ylavic <yl...@gmail.com> wrote:
>
> Is there something I can #ifdef (or check at configure/run time) for
> SLELS11 or the kernel? This would document in the test that a minimal
> timeout is usually expected, but on this platform/kernel. Or I'll use
> 190ms for everyone, which looks "unfair".
Does r1908616 work for you?
>
> Regards;
> Yann.
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Rainer;
On Mon, Mar 20, 2023 at 10:31 PM Rainer Jung <ra...@kippdata.de> wrote:
>
> Am 17.03.23 um 15:11 schrieb Yann Ylavic:
> >
> > Hm OK, these commits were meant to address that precisely..
> > It looks like SLES has some special epoll_wait() implementation that
> > can return before the timeout. Could you printf the t2 - t1 diff in
> > the justsleep() test after apr_pollset_poll()? It could be interesting
> > to know if it's almost 200ms or close to zero (the latter could mean
> > epoll_wait() does not block if there is no fd in the pollset, which is
> > the case in this test).
>
> The observed time delta on this platform is between 197 and 198.5 ms
> instead of somewhat above 200ms. I should note it is an old patch level
> of SLES 11 using kernel 2.6.32.12-0.7.
>
> There are some old informations about the rounding of the timeout:
>
> https://linux-fsdevel.vger.kernel.narkive.com/9jp0o6FA/bug-epoll-wait-timeout-is-shorter-than-requested
Thanks for looking. Well, it seems that there is no guarantee of a
minimal timeout on this system.
There is something fishy though, the only change w.r.t. before is the
millisecond round _up_..
>
> On this system HZ is 100, so a jiffie is 10ms and probably this means it
> should suffice to accept 200-10=190ms as the minimum sleep time.
Is there something I can #ifdef (or check at configure/run time) for
SLELS11 or the kernel? This would document in the test that a minimal
timeout is usually expected, but on this platform/kernel. Or I'll use
190ms for everyone, which looks "unfair".
Regards;
Yann.
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Yann,
Am 17.03.23 um 15:11 schrieb Yann Ylavic:
> On Fri, Mar 17, 2023 at 2:30 PM Rainer Jung <ra...@kippdata.de> wrote:
>>
>> Am 17.03.23 um 14:12 schrieb Yann Ylavic:
>>> On Fri, Mar 17, 2023 at 11:20 AM Rainer Jung <ra...@kippdata.de> wrote:
>>>>
>>>> But: testpoll fails:
>>>>
>>>> testpoll : Line 897: apr_pollset_poll() didn't sleep
>>>>
>>>> Unfortunately I don't know when it started. Any idea, what I should
>>>> investigate?
>>>>
>>>> All this is on SLES11, haven't tried the recent APR trunk with newer
>>>> Linuxes, but r1908005 worked on them including testpoll tests.
>>>
>>> I suppose SLES11 is using epoll implementation, so r1902236 and
>>> r1902258 may help.
>>> Does your APR contain those?
>>>
>>> Regards;
>>> Yann.
>>
>> Yes, it contained everything until r1908442.
>
> Hm OK, these commits were meant to address that precisely..
> It looks like SLES has some special epoll_wait() implementation that
> can return before the timeout. Could you printf the t2 - t1 diff in
> the justsleep() test after apr_pollset_poll()? It could be interesting
> to know if it's almost 200ms or close to zero (the latter could mean
> epoll_wait() does not block if there is no fd in the pollset, which is
> the case in this test).
The observed time delta on this platform is between 197 and 198.5 ms
instead of somewhat above 200ms. I should note it is an old patch level
of SLES 11 using kernel 2.6.32.12-0.7.
There are some old informations about the rounding of the timeout:
https://linux-fsdevel.vger.kernel.narkive.com/9jp0o6FA/bug-epoll-wait-timeout-is-shorter-than-requested
On this system HZ is 100, so a jiffie is 10ms and probably this means it
should suffice to accept 200-10=190ms as the minimum sleep time.
Best regards,
Rainer
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Mar 17, 2023 at 2:30 PM Rainer Jung <ra...@kippdata.de> wrote:
>
> Am 17.03.23 um 14:12 schrieb Yann Ylavic:
> > On Fri, Mar 17, 2023 at 11:20 AM Rainer Jung <ra...@kippdata.de> wrote:
> >>
> >> But: testpoll fails:
> >>
> >> testpoll : Line 897: apr_pollset_poll() didn't sleep
> >>
> >> Unfortunately I don't know when it started. Any idea, what I should
> >> investigate?
> >>
> >> All this is on SLES11, haven't tried the recent APR trunk with newer
> >> Linuxes, but r1908005 worked on them including testpoll tests.
> >
> > I suppose SLES11 is using epoll implementation, so r1902236 and
> > r1902258 may help.
> > Does your APR contain those?
> >
> > Regards;
> > Yann.
>
> Yes, it contained everything until r1908442.
Hm OK, these commits were meant to address that precisely..
It looks like SLES has some special epoll_wait() implementation that
can return before the timeout. Could you printf the t2 - t1 diff in
the justsleep() test after apr_pollset_poll()? It could be interesting
to know if it's almost 200ms or close to zero (the latter could mean
epoll_wait() does not block if there is no fd in the pollset, which is
the case in this test).
Regards;
Yann.
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Rainer Jung <ra...@kippdata.de>.
Am 17.03.23 um 14:12 schrieb Yann Ylavic:
> On Fri, Mar 17, 2023 at 11:20 AM Rainer Jung <ra...@kippdata.de> wrote:
>>
>> But: testpoll fails:
>>
>> testpoll : Line 897: apr_pollset_poll() didn't sleep
>>
>> Unfortunately I don't know when it started. Any idea, what I should
>> investigate?
>>
>> All this is on SLES11, haven't tried the recent APR trunk with newer
>> Linuxes, but r1908005 worked on them including testpoll tests.
>
> I suppose SLES11 is using epoll implementation, so r1902236 and
> r1902258 may help.
> Does your APR contain those?
>
> Regards;
> Yann.
Yes, it contained everything until r1908442.
configure output contains:
ac_cv_define_POLLIN=yes
ac_cv_func_poll=yes
ac_cv_header_poll_h=yes
ac_cv_header_sys_poll_h=yes
apr_cv_epoll=yes
apr_cv_epoll_create1=yes
#define HAVE_POLL 1
#define HAVE_EPOLL 1
#define HAVE_EPOLL_CREATE1 1
#define HAVE_POLL_H 1
#define HAVE_SYS_POLL_H 1
#define HAVE_POLLIN 1
#define WAITIO_USES_POLL 1
Thanks and regards,
Rainer
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Mar 17, 2023 at 11:20 AM Rainer Jung <ra...@kippdata.de> wrote:
>
> But: testpoll fails:
>
> testpoll : Line 897: apr_pollset_poll() didn't sleep
>
> Unfortunately I don't know when it started. Any idea, what I should
> investigate?
>
> All this is on SLES11, haven't tried the recent APR trunk with newer
> Linuxes, but r1908005 worked on them including testpoll tests.
I suppose SLES11 is using epoll implementation, so r1902236 and
r1902258 may help.
Does your APR contain those?
Regards;
Yann.
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Rainer Jung <ra...@kippdata.de>.
Thanks Yann, configure now detects the missing function.
But: testpoll fails:
testpoll : Line 897: apr_pollset_poll() didn't sleep
Unfortunately I don't know when it started. Any idea, what I should
investigate?
All this is on SLES11, haven't tried the recent APR trunk with newer
Linuxes, but r1908005 worked on them including testpoll tests.
Thanks and regards,
Rainer
Am 16.03.23 um 16:27 schrieb Rainer Jung:
> It should, I will try later and report back. Thanks!
>
> Am 16.03.23 um 15:06 schrieb Yann Ylavic:
>> On Thu, Mar 16, 2023 at 2:53 PM Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>
>>> I have very little knowledge about autoconf stuff. The autoconf part
>>> was suggest by Yann in [1]
>>>
>>> Yann: do you have any ideas why it does not work?
>>
>> Does r1908438 fix it for you Rainer?
>>
>> Regards;
>> Yann.
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Rainer Jung <ra...@kippdata.de>.
It should, I will try later and report back. Thanks!
Am 16.03.23 um 15:06 schrieb Yann Ylavic:
> On Thu, Mar 16, 2023 at 2:53 PM Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> I have very little knowledge about autoconf stuff. The autoconf part was suggest by Yann in [1]
>>
>> Yann: do you have any ideas why it does not work?
>
> Does r1908438 fix it for you Rainer?
>
> Regards;
> Yann.
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Mar 16, 2023 at 2:53 PM Ivan Zhakov <iv...@visualsvn.com> wrote:
>
> I have very little knowledge about autoconf stuff. The autoconf part was suggest by Yann in [1]
>
> Yann: do you have any ideas why it does not work?
Does r1908438 fix it for you Rainer?
Regards;
Yann.
Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Posted by Ivan Zhakov via dev <de...@apr.apache.org>.
Hello Rainer,
I have very little knowledge about autoconf stuff. The autoconf part was
suggest by Yann in [1]
Yann: do you have any ideas why it does not work?
Thanks!
[1] https://lists.apache.org/thread/6j6zm4x15ng04y3tws4w0zoc7vhx3fp8
On Thu, 16 Mar 2023 at 16:01, Rainer Jung <ra...@kippdata.de> wrote:
> Hello Ivan,
>
> Am 21.01.23 um 17:13 schrieb ivan@apache.org:
> > Author: ivan
> > Date: Sat Jan 21 16:13:27 2023
> > New Revision: 1906889
> >
> > URL: http://svn.apache.org/viewvc?rev=1906889&view=rev
> > Log:
> > Merge thread-name branch (PR 60587) [1]:
> > * Introduce apr_thread_name_set() and apr_thread_name_get().
> >
> > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60587
> > [2] https://lists.apache.org/thread/z24logzc6v8tc0p2q3375cc10qo9y5yw
> >
> > Modified:
> > apr/apr/trunk/ (props changed)
> > apr/apr/trunk/build/apr_threads.m4
> > apr/apr/trunk/configure.in
> > apr/apr/trunk/include/apr_thread_proc.h
> > apr/apr/trunk/include/arch/win32/apr_arch_misc.h
> > apr/apr/trunk/test/testthread.c
> > apr/apr/trunk/threadproc/beos/thread.c
> > apr/apr/trunk/threadproc/netware/thread.c
> > apr/apr/trunk/threadproc/os2/thread.c
> > apr/apr/trunk/threadproc/unix/thread.c
> > apr/apr/trunk/threadproc/win32/thread.c
> >
> > Propchange: apr/apr/trunk/
> >
> ------------------------------------------------------------------------------
> > Merged /apr/apr/branches/thread-name:r1902296-1906888
> >
> > Modified: apr/apr/trunk/build/apr_threads.m4
> > URL:
> http://svn.apache.org/viewvc/apr/apr/trunk/build/apr_threads.m4?rev=1906889&r1=1906888&r2=1906889&view=diff
> >
> ==============================================================================
> > --- apr/apr/trunk/build/apr_threads.m4 (original)
> > +++ apr/apr/trunk/build/apr_threads.m4 Sat Jan 21 16:13:27 2023
> > @@ -312,3 +312,27 @@ elif test "$apr_cv_mutex_robust_shared"
> > [Define if non-posix/portable cross-process robust
> mutexes are available])
> > fi
> > ])
> > +
> > +
> > +dnl Check for pthread_setname_np
> > +dnl Note: Only detects two-arg version
> > +AC_DEFUN([APR_CHECK_PTHREAD_SETNAME_NP], [
> > +AC_CACHE_CHECK([for pthread_setname_np support],
> > +[apr_cv_pthread_setname_np], [
> > +AC_TRY_COMPILE([
> > +#include <pthread.h>
> > +],[
> > +pthread_t td = pthread_self();
> > +pthread_setname_np(td, "name");
> > +],[
> > + apr_cv_pthread_setname_np=yes
> > +],[
> > + apr_cv_pthread_setname_np=no
> > +])])
> > +
> > +if test "$apr_cv_pthread_setname_np" = "yes"; then
> > + AC_DEFINE([HAVE_PTHREAD_SETNAME_NP], 1,
> > + [Define if pthread_setname_np is available])
> > +fi
> > +])dnl
> > +
>
> Thsi configure check does *not* fail for me on SLES 11 where
> pthread_[gs]ername_np is not available. In config.log I find
>
> warning: implicit declaration of function ‘pthread_setname_np’
>
> but configure procees with a "yes". The buidl then succeeds, but the
> library is not usable due to the unresolvable symbol.
>
> Best regards,
>
> Rainer
>
--
Ivan Zhakov