I don't see a good reason why hSelect couldn't be changed to take
a TimeVal, as you suggest:
data TimeVal
= TimeVal { tv_sec :: Int
, tv_usec :: Int
}
I would either rely on the fact that the rep. of ClockTime is
exposed or write my own gettimeofday() (or equiv) wrapper.
--sigbjorn
> -----Original Message-----
> From: Ian Jackson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 01, 1999 3:04 PM
> To: [EMAIL PROTECTED]
> Subject: GHC Select and Time modules - struct timeval
>
>
> Firstly, let me say that I'm very new to Haskell, so it may be that
> I'm just going about things in a fundamentally wrong way.
>
> I'm writing an application in Haskell which, if I were to write it in
> C, would be an event-driven select-loop based program. It needs to
> handle timeouts, and know when particular external (network) events
> happen.
>
> I was pleased to see that GHC has a library misc/Select which will
> allow me to call select(2). This will allow me to build the
> event-processing arrangements.
>
> My first observation is that the timeout is represented as a TimeOut,
> which is Maybe Int, where the integer is in microseconds. Ints only
> have an advertised range of around +/-2^29, which corresponds to
> something under 10 minutes. This is too short for my application. I
> think that Select.TimeOut should be Maybe Integer - or, alternatively,
> that a new type TimeVal or something should be created to represent
> the full precision and range of struct timeval, and then TimeOut would
> be Maybe TimeVal.
>
> My second problem is that to know what timeout parameter to pass to
> select I need to know what the current time is, to the precision of
> the timeout for select. In a C program I would use gettimeofday,
> which (effectively) returns a struct timeval.
>
> GHC does provide access to gettimeofday in the form of the
> getClockTime call in the std/Time library. It returns a ClockTime,
> which, as the comments suggest, is advertised in the Library Report
> only as an abstract type. In fact, the ClockTime is concrete in GHC
> and is pretty much the TimeVal type I suggest above.
>
> However, arithmetic operations on ClockTimes all take place after
> conversion to and from civil time (y/m/d/h/m/s&c). I can't take
> ClockTimes and simply (eg) add a number of us to calculate the next
> event point, or subtract a pair of ClockTimes to get the core of a
> TimeOut - without unpicking it myself and converting to an Integer,
> anyway.
>
> So, it all seems somewhat irregular. This clearly needs to be fixed,
> and I think I can do it, but in order for my patch to be accepted I
> think I should ask what the best way would be.
>
> Questions include:
>
> * Is it reasonable to consider the internal construction of a
> ClockTime exposed ? (I presume not.)
>
> * Should there be a conversion from ClockTime to Integer ? In what
> units should the Integer be - us or ps ?
>
> * How much is the interface in misc/Select.lhs cast in stone ? Would
> it be reasonable to simply change hSelect to take an Integer, or a
> ClockTime ?
>
> Any and all advice, specific or general, appreciated.
>
> Ian.
>
>
