thanx for the reply. It seems to be what I expected. Let me ask a more
concrete question. Imagine I have two event processors based on
TTimer.Notify(). Now I want to be sure that the first one will be triggered
every say 30 ms, otherwise I may lose data. Now as soon as the second one
is triggered, the first one should wait until the second one Notify() is
completed. And that's not good. Can this situation be resolved somehow? Of
course I can (as you suggest) use Notify of the second processor to set a
flag and then check for this flag in the very body of the program, but that
doesn't seem to be an elegant solution especially if several processes with
different priorities should be run "in parallel". (well, if you have only
one process which must actually do something every 30 ms or so and let all
the other job to be done "when convenient time comes" it is OK, but if you
have two processes with certain scheduling ... ). I m still voting for a
Java-like solution :))
Always,
Dr. Anton Fokin
Division of Cosmic and Subatomic Physics
Lund University
Sweden
----------
> From: Fons Rademakers <Fons.Rademakers@cern.ch>
> To: Anton Fokin <kosu_fokin@garbo.lucas.lu.se>
> Cc: roottalk@hpsalo.cern.ch
> Subject: Re: TTimer
> Date: den 12 March 1999 16:12
>
> Hi Anton,
>
> timers never trigger at the same time or when in a TTimer::Notify.
> Little explanation:
>
> - there are two types of timers synchronous and a-synchronous.
> - synchronous timers are only handled via the ROOT eventloop
> (see TUnixSystem::DispatchOneEvent()). If there are no
mouse/keyboard
> events then the synchronous timer queue is checked. So if the
processing
> of a mouse/keyboard event takes a long time synchronous timers are
not
> called for a while. To prevent this from happening one can call in
long
> procedures gSystem->ProcessEvents(). The system schedules only the
> next timer in the queue when the current one's Notify() has
finished.
> - a-synchronous timers are triggered via SIGALARM, i.e. the program is
> interupted and execution jumps to the Notify() function. When the
> notify is finished the next a-sync timer is scheduled and the system
> resumes from the place where it was initially interrupted. One of
the
> things to remember when using a-sync timers is don't make any
graphics
> calls in them. X11 is not re-entrant and it might be that the
SIGALARM
> signal interrupted the system while being in X11. A-sync timers are
best
> used to set flags that you can test at a convenient and controlled
> time.
>
> Hope this helps.
>
>
> Cheers, Fons.
>
>
>
> Anton Fokin wrote:
> >
> > Hi there,
> >
> > well, I am curious what happens if one sets up two TTimer derived
objects
> > and FirstTimer.Notify() call comes while SecondTimer.Notify() is
executing.
> > I would also like to know 1. if there is any way to protect a portion
of
> > code in a way it is done in Java (synchronized()) 2. If I can set any
> > "priorities" for timer calls. (Well, to get this discussion useful for
all
> > rooters let's assume that I am a lamer in Unix/whatsoever system
> > programming and do not know much about system calls (semaphores, etc.))
:)
> >
> > Always yours,
> >
> > Dr. Anton Fokin
> >
> > Division of Cosmic and Subatomic Physics
> > Lund University
> > Sweden
>
> --
> Org: CERN, European Laboratory for Particle Physics.
> Mail: 1211 Geneve 23, Switzerland
> E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248
> WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910