Opened 6 years ago

Last modified 5 months ago

#770 new defect

Enquire::set_time_limit() doesn't work on NetBSD

Reported by: Olly Betts Owned by: Olly Betts
Priority: normal Milestone: 2.0.0
Component: Library API Version: 1.4.7
Severity: minor Keywords:
Cc: Blocked By:
Blocking: Operating System: NetBSD

Description

Testcase matchtimelimit1 fails because the timeout doesn't actually fire. Reproduced with current RELEASE/1.4 and master.

I've debugged a bit and both timer_create() and timer_settime() seem to succeed. I also tried all four timers which seem to be available with the same results (we usually use CLOCK_MONOTONIC if we can, otherwise CLOCK_REALTIME):

#define CLOCK_REALTIME  0
#define CLOCK_VIRTUAL   1
#define CLOCK_PROF      2
#define CLOCK_MONOTONIC 3

NetBSD has a TIMER_RELTIME constant to pass in flags, which Linux at least doesn't, and the NetBSD man page implies you need to specify TIMER_RELTIME or TIMER_ABSTIME - however from the header this isn't the problem:

#if defined(_NETBSD_SOURCE)
#define TIMER_RELTIME   0x0     /* relative timer */
#endif

And indeed specifying TIMER_RELTIME in flags doesn't help.

Severity minor, since this doesn't seem to be a widely used feature, and isn't supported on all platforms anyway. This ticket is because it looks like it ought to work on NetBSD, but doesn't (and because a testcase fails as a result of that).

Change History (5)

comment:1 by Olly Betts, 6 years ago

I've added NetBSD to the list of platforms where we won't try to use timer_create() for now.

There are rather a lot of platforms where the POSIX timer machinery either isn't implemented at all, or appears to be but it doesn't actually work (at least as we want to use it).

I wonder if we'd actually do better to launch a thread which does a fine granularity sleep for the timeout length.

comment:2 by Olly Betts, 13 months ago

I worked out the problem on NetBSD - it's that SIGEV_THREAD is not implemented (still true in NetBSD 9.2). This information is near the top of man sigevent.

I tried a pthread-based implementation, which works on Linux at least. I wonder if using standard C++ thread functionality would be simpler (we'd avoid having to mess with probing for pthreads stuff, which looks a bit of a mess from https://www.gnu.org/software/autoconf-archive/ax_pthread.html - some platforms require a different compiler even!) It would also give us support for non-pthreads platforms (__WIN32__ being the main one). The downside is I think we need std::jthread which was added in C++20, rather than std::thread which is C++11.

Last edited 13 months ago by Olly Betts (previous) (diff)

comment:3 by Olly Betts, 13 months ago

Milestone: 1.5.0

comment:4 by Olly Betts, 12 months ago

#769 could use a similar approach to allow blocking for a write lock for up to X seconds.

comment:5 by Olly Betts, 5 months ago

Milestone: 1.5.02.0.0

Postponing as this only affects one fairly obscure feature on one platform, and will be simpler to do once we can reasonably just require C++20.

Note: See TracTickets for help on using tickets.