diff options
| author | root <root> | 2007-11-12 08:57:03 +0000 | 
|---|---|---|
| committer | root <root> | 2007-11-12 08:57:03 +0000 | 
| commit | f5ec6b1704865fe388e76e6689cda413c0fe4f0a (patch) | |
| tree | 29eeaef3f9425a40d707b1db97a2cc3113e8b8fa | |
| parent | a8e6a8108ea5864a982d064fa5fa1eb5ac6dafd3 (diff) | |
*** empty log message ***
| -rw-r--r-- | ev.pod | 6 | 
1 files changed, 4 insertions, 2 deletions
| @@ -41,7 +41,7 @@ support for multiple event loops, then all functions taking an initial  argument of name C<loop> (which is always of type C<struct ev_loop *>)  will not have this argument. -=head1 TIME AND OTHER GLOBAL FUNCTIONS +=head1 TIME REPRESENTATION  Libev represents time as a single floating point number, representing the  (fractional) number of seconds since the (POSIX) epoch (somewhere near @@ -49,6 +49,8 @@ the beginning of 1970, details are complicated, don't ask). This type is  called C<ev_tstamp>, which is what you should use too. It usually aliases  to the double type in C. +=head1 GLOBAL FUNCTIONS +  =over 4  =item ev_tstamp ev_time () @@ -101,7 +103,7 @@ types of such loops, the I<default> loop, which supports signals and child  events, and dynamically created loops which do not.  If you use threads, a common model is to run the default event loop -in your main thread (or in a separate thrad) and for each thread you +in your main thread (or in a separate thread) and for each thread you  create, you also create another event loop. Libev itself does no locking  whatsoever, so if you mix calls to the same event loop in different  threads, make sure you lock (this is usually a bad idea, though, even if | 
