timer

timer

[Anastasia Gornostaeva]

Hello.

Does exist Timer module, that allows me add/reset/remove timed events?
Currently I use Unix.setitimer() for my simple implementation that allows
only adding new events into a queue, but my skills is not enough to implement
reset and remove events from the Timer queue.
And I'm not sure if using Unix.sleep() with setitimer() is safely (without
Threads).
Thanks.

ermine

Re: [Caml-list] timer

[SooHyoung Oh]

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

I have one at http://pllab.kaist.ac.kr/~shoh/ocaml/libs/timer/ .


  Module Timer
  <http://pllab.kaist.ac.kr/%7Eshoh/ocaml/libs/timer/doc/type_Timer.html>


module Timer: |sig| .. <http://pllab.kaist.ac.kr/%7Eshoh/ocaml/libs/timer/doc/Timer.html> |end|

timer library. This library uses Sys module and unix, thread library.
------------------------------------------------------------------------

type ||id 

callback id. This is returned from registering timer callback and used 
for unregistering.

val init : |?tck_unit:float -> unit -> unit|

initializer timer library. This should be called before calling any 
timer function.

|tck_unit| : tick unit of tick timer. (default value is 100 milli seconds)

val reset : |unit -> unit|

reset timer library. Timer functions can be called anymore.

val register : |(unit -> unit) -> float -> float -> id <http://pllab.kaist.ac.kr/%7Eshoh/ocaml/libs/timer/doc/Timer.html#TYPEid>|

register callback. /register f start interval/ registers callback 
fucntion /f/ which will be called after /start/ milli seconds at first 
and every /interval/ milli seconds after the first calling. If 
/interval/ is zero, the callback function is called only once.
*Returns* id the registered callback id.

val unregister : |id <http://pllab.kaist.ac.kr/%7Eshoh/ocaml/libs/timer/doc/Timer.html#TYPEid> -> unit|

unregister callback.

val msleep : |float -> unit|

sleep for the given time in milli seconds.

Anastasia Gornostaeva ? ?:

>Hello.
>
>Does exist Timer module, that allows me add/reset/remove timed events?
>Currently I use Unix.setitimer() for my simple implementation that allows
>only adding new events into a queue, but my skills is not enough to implement
>reset and remove events from the Timer queue.
>And I'm not sure if using Unix.sleep() with setitimer() is safely (without
>Threads).
>Thanks.
>
>ermine
>
>_______________________________________________
>Caml-list mailing list. Subscription management:
>http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>Archives: http://caml.inria.fr
>Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>  
>

[-- Attachment #2: Type: text/html, Size: 3672 bytes --]

Re: [Caml-list] timer

[Anastasia Gornostaeva]

On Tue, Jan 04, 2005 at 10:11:06AM +0900, SooHyoung Oh wrote:

>  Module Timer
>  <http://pllab.kaist.ac.kr/%7Eshoh/ocaml/libs/timer/doc/type_Timer.html>

This module does not work when is compiled for native-code mode and is linked
with libc_r under FreeBSD 5.x 
As bytecode it works perfectly, but i want native-code.

Executing of native-code test:

bash-2.05b$ ./tst
Sleeping for 1 sec: 1107199242.936151
Waked: 1107199243.038147
Sleeping for 2 sec: 1107199243.038242
Waked: 1107199245.038524
Sleeping for 300 msec: 1107199245.039142
^C

Here it stops and eats CPU up to 99% (it does not hang up). 
I guess it is non-portability of ocaml (i have only 3.08.2)
The same shit happens when I use setitimer: my programs sees 1-3 alrarm
signals and does not see alarms signals anymore.

Any idea?

ermine

Re: [Caml-list] timer

[Alain Frisch]

Anastasia Gornostaeva wrote:
> This module does not work when is compiled for native-code mode and is linked
> with libc_r under FreeBSD 5.x 
> As bytecode it works perfectly, but i want native-code.

It seems that the support for threads is broken in FreeBSD. Maybe this
explains your problems. From GODI FAQ:


----------------------------------------------------------------------
Why are POSIX threads disabled for FreeBSD?
----------------------------------------------------------------------

Because they don't work well enough, i.e. there is a problem in
the threading implementation of FreeBSD.

For a description of the problem, see tickets 1820, 1821 of the O'Caml
bug database:

http://caml.inria.fr/bin/caml-bugs/not%20a%20bug?id=1820;page=47;user=guest
http://caml.inria.fr/bin/caml-bugs/not%20a%20bug?id=1821;page=48;user=guest


-- Alain

Re: [Caml-list] timer

[Ville-Pertti Keinonen]

On Mon, 2005-01-31 at 22:33 +0300, Anastasia Gornostaeva wrote:
> On Tue, Jan 04, 2005 at 10:11:06AM +0900, SooHyoung Oh wrote:
> 
> >  Module Timer
> >  <http://pllab.kaist.ac.kr/%7Eshoh/ocaml/libs/timer/doc/type_Timer.html>
> 
> This module does not work when is compiled for native-code mode and is linked
> with libc_r under FreeBSD 5.x 

Did you intentionally link against libc_r, or are you running a
pre-stable version of 5.x?

libpthread is the default for FreeBSD 5.x since before becoming the
stable branch and 6-current, and it should work correctly (verified for
-current).

Re: [Caml-list] timer

[Anastasia Gornostaeva]

On Tue, Feb 01, 2005 at 09:50:35AM +0200, Ville-Pertti Keinonen wrote:

> > >  Module Timer
> > >  <http://pllab.kaist.ac.kr/%7Eshoh/ocaml/libs/timer/doc/type_Timer.html>
> > 
> > This module does not work when is compiled for native-code mode and is linked
> > with libc_r under FreeBSD 5.x 
> 
> Did you intentionally link against libc_r, or are you running a
> pre-stable version of 5.x?
> 
> libpthread is the default for FreeBSD 5.x since before becoming the
> stable branch and 6-current, and it should work correctly (verified for
> -current).

I have different FreeBSDs, 5.2rc2 and 5.3-release. 
On 5.2rc2 using libc_r is by default but just now I use libmap.conf only for 
ocaml-compiled programs to use pthreads. 
I still dont believe it is only freebsd related problem if i use 
freebsd 5.2rc2 for long time and with wide range of sowtware without 
problems. For example, on my machine there is running Zope based on python 2.1,
that is linked against libc_r. Well, i dont know if it uses signals ...

How can I reproduce this problem on C? A probram below does not lose signals

#include <signal.h>
#include <stdio.h>

void sig_handler(int s)
{
        // stderr is preferred because it is non-buffered
        fprintf(stderr, "Got signal: %d\n", s);
}

int main(int argc, char ** argv)
{
        printf("Starting...\n");
        signal(SIGALRM, sig_handler);
        signal(SIGUSR1, sig_handler);
        signal(SIGUSR2, sig_handler);
        printf("Handlers installed...\n");
        while(1)
        {
                if(!sleep(5))
                        fprintf(stderr, "tick!\n");
                else
                        perror("sleep");
        }
}

Compilation: 
gcc test.o -o test -pthread
gcc test.o -o test -lc_r
and playing with library mapping in libmap.conf
Using: run it ad manually send killall -SIGALRM test
All is fine.

ermine

Re: [Caml-list] timer

[Ville-Pertti Keinonen]

On Tue, 2005-02-01 at 15:22 +0300, Anastasia Gornostaeva wrote:

> I have different FreeBSDs, 5.2rc2 and 5.3-release. 
> On 5.2rc2 using libc_r is by default but just now I use libmap.conf only for 
> ocaml-compiled programs to use pthreads. 

Does it work correctly for you when using libpthread on 5.2rc2 (it
might've still been called libkse)?

Does it work correctly with 5.3-release?  (I'd definitely expect it to.)

> I still dont believe it is only freebsd related problem if i use 
> freebsd 5.2rc2 for long time and with wide range of sowtware without 
> problems. For example, on my machine there is running Zope based on python 2.1,
> that is linked against libc_r. Well, i dont know if it uses signals ...

libc_r works most of the time, including signals, but OCaml makes a
particular misbehavior easy to trigger.

This is getting somewhat off-topic, but it still relates to getting
OCaml programs to work correctly, so...

Based on a quick look at the libc_r sources, it seems that what actually
happens is when entering a signal handler, the signal being delivered is
masked (as is sa_mask), and when leaving the handler, the original
signal mask is restored...as long as it hasn't been changed by the
signal handler.  OCaml always modifies the signal mask inside the
handler.

This seems like a misreading of the standard.  According to SUS3:

    When a signal is caught by a signal-catching function installed
    by sigaction(), a new signal mask is calculated and installed for
    the duration of the signal-catching function (or until a call to
    either sigprocmask() or sigsuspend() is made).

    ...

    If and when the user's signal handler returns normally, the
    original signal mask is restored.

Apparently the author of libc_r interpreted the "or until a call to
either sigprocmask() or sigsuspend() is made" to also cancel the
restoration of the original mask.

If you must use libc_r, the following modification might fix the problem
(disclaimer - I haven't tested it):

--- uthread_sig.c.orig  Wed Dec  3 08:54:40 2003
+++ uthread_sig.c       Tue Feb  1 15:52:53 2005
@@ -1112,12 +1112,14 @@
     struct pthread_signal_frame *psf)
 {
        memcpy(&thread->ctx, &psf->ctx, sizeof(thread->ctx));
+#if 0
        /*
         * Only restore the signal mask if it hasn't been changed
         * by the application during invocation of the signal handler:
         */
        if (thread->sigmask_seqno == psf->saved_state.psd_sigmask_seqno)
+#endif
                thread->sigmask = psf->saved_state.psd_sigmask;
        thread->curframe = psf->saved_state.psd_curframe;
        thread->wakeup_time = psf->saved_state.psd_wakeup_time;
        thread->data = psf->saved_state.psd_wait_data;