Re: [eclipse-clp-users] set_flag(after_event_timer, virtual) on Linux

[Joachim S. <jsc...@co...>]

Hi Chris,

thanks for your feedback. Indeed, the documentation is not up to date in places 
here!

With the introduction of multithreading in version 7.0, the *after*-event 
functionality was completely reimplemented. It previously relied on Unix signal 
handling, but is now portably built on top of a timer-thread (both on Windows 
and Unix). Unfortunately, that meant the loss of the capability to choose 
between real and virtual/cpu time (which was supported on Unix previously).

There is at the moment no portable way of basing an event on CPU time directly.  
You could build something approximate by using real time events and then looking 
at CPU time in the handler. The relevant facilities in versions 7.x are:

  * after-events
    <http://eclipseclp.org/doc/bips/kernel/event/event_after-2.html> (see
    event_after/2, event_after_every/2 etc):
      o real (wall clock) time based
      o thread safe, affect only the calling thread
  * lib(timeout) <http://eclipseclp.org/doc/bips/lib/timeout/index.html>: based
    on after-events, same properties
  * cputime(T) <http://eclipseclp.org/doc/bips/kernel/opsys/cputime-1.html> and
    statistics(cputime, T): retrieve the cpu time of the calling thread (will be
    less than elapsed real time)
  * statistics(times, [T,_,_])
    <http://eclipseclp.org/doc/bips/kernel/env/statistics-2.html>: gives the cpu
    time for the whole process, i.e. the sum of all thread cpu times (may be
    more than elapsed real time)


Having said that, on Unix platforms it is still possible to raise an event based 
on (process) CPU time, by using set_interrupt_handler/2 
<http://eclipseclp.org/doc/bips/kernel/event/set_interrupt_handler-2.html> and 
the deprecated set_timer/2 
<http://eclipseclp.org/doc/bips/kernel/obsolete/set_timer-2.html>, for example:

    ?- set_interrupt_handler(vtalrm, throw/1).
    Yes (0.00s cpu)

    ?- set_timer(virtual, 3), catch((repeat,fail), vtalrm, writeln("Timed out")).
    Timed out
    Yes (3.00s cpu)

The problem with this (and the reason set_timer/2 was deprecated) is that

  * it's not supported on Windows
  * it's uses total process (rather than per-thread) CPU time
  * the event is posted only to the thread that called set_interrupt_handler/2

I can see that it would be useful to have a variant of after-events triggered by 
the exhaustion of a CPU time allocation, or even other resource limits!

Further comments inline below...


On 24/09/2024 21:54, Chris Meudec wrote:
> HI,
> I am using ECLiPSe 7.1 on Ubuntu, and using after events for the first time.
>
> all is well except that the flag after_event_timer is set on "real" timer by 
> default which I take to be "real time elapsed since the start of the ECLiPSe 
> session" in other words wall-time which does not represent processing time (or 
> cpu time) due to OS scheduling.
>
> When in Linux  (Ubuntu 24.04) I do:
>
> set_flag(after_event_timer, virtual). %causes out of range when set to virtual 
> (what I need I think) but is ok for real: checked in tkeclipse and from CLI
>
> So it looks like it is no longer available in Linux either.

Yes, sorry, should have been mentioned in the release notes and documentation 
more properly sanitised...


> It's no big deal, I think, but it will introduce variability in execution 
> making some results hard to reproduce as I use after events to abort (via an 
> exception) some of my optimisation problems searches.

Yes, that is a clear use case.


>
> Also the documentation says: "In addition, the users should not make use of 
> these timers for their own purposes if they plan to use the after event 
> mechanism." in last sentence of paragraph 14.1.2 which I do not understand.

This warning no longer applies - after events no longer rely on timers.


>
> I would like to set an after event that is associated with user cputime to 
> avoid variations between runs: is that possible in Linux?
>
> And although I am not quite there yet, if and when I do move to using Engine 
> and Threads I am right to assume that every thread (engine?) will use its own 
> 'real' time (assuming cpu time is not available)?

The real/wall/elapsed time is a single shared clock, but every thread has its 
own CPU time, as measured by cputime/1.


>
> Thanks for the support.
> Chris
> --
> Dr Chris Meudec <http://www.echancrure.eu/> (he/him) Maitrise, PhD, MA (T&L)
> Lecturer in Software Development
> South East Technological University - Carlow Campus - Ireland
> E chr...@se... <mailto:chr...@se...> |  *setu.ie 
> <https://setu.ie/>*
> turn on images <https://setu.ie/>
>
> Kilkenny Road Campus, Kilkenny Road, Carlow, R93 V960, Ireland
> Campas Bhóthar Chill Chainnigh, Bóthar Chill Chainnigh, Ceatharlach, R93 V960, 
> Éire
>