From: Yohanes Santoso <ysantoso-rubytalk@...>
Date: 2005-10-21T22:26:08+09:00
Subject: Re: Threads, timing and HTTP

Alexander Lamb <Alexander.J.Lamb@sim.hcuge.ch> writes:

> However, this is a problem. Indeed, I want also to measure the time
> (round-trip) it takes for the ping (these are only simple pings for
> the time being). As you can see I get the local time before and after
> the call.

> But this doesn't work with threads. Indeed, since the process is
> shared among threads, the time will be dependent on the number of
> threads I am running and not a correct view of the actual time it
> takes to ping.

Using process instead of thread would also have the same problem. You
still can't guarantee that your execution path is not suspended
between start time to end time; the CPU is still shared among
processes.

You'd have to use an OS that can give you this guarantee. The catch
is, there is no port of ruby to such OS yet.

But probably you don't need a guarantee, just a 'good enough' is good
enough. In this case, there is little benefit made from using
processes, and personally, I won't bother to do so for a simple
monitoring program.

> I can't define the piece of code between the two times as critical

Even if you define it, you can't count on the ruby process not being
suspended by some external factors.

The fundamental problem is simple: limited resources. As long as there
are multiple executions desiring access to the same resources (cpu
time, network time), there is bound to be some contentions.

> Any idea? Maybe use processes instead of threads?

For critical monitoring services, one use an OS that can guarantee
some amount of cpu time within some duration to a process. Examples of
this is found in many places like in your car's ABS controller and
your local neighbourhood's nuclear power station.

YS.