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 /ev.pod | |
parent | a8e6a8108ea5864a982d064fa5fa1eb5ac6dafd3 (diff) |
*** empty log message ***
Diffstat (limited to 'ev.pod')
-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 |