[ViewVC] Diff of: cvs/libeio/eio.pod

Comparing libeio/eio.pod (file contents):
Revision 1.17 by root, Tue Jul 5 18:59:28 2011 UTC vs.
Revision 1.24 by sf-exg, Thu Jul 14 08:51:29 2011 UTC

 If C<eio_poll ()> is configured to not handle all results in one go
 (i.e. it returns C<-1>) then you should start an idle watcher that calls
 C<eio_poll> until it returns something C<!= -1>.
-A full-featured conenctor between libeio and libev would look as follows
+A full-featured connector between libeio and libev would look as follows
 (if C<eio_poll> is handling all requests, it can of course be simplified a
 lot by removing the idle watcher logic):
   static struct ev_loop *loop;
   static ev_idle repeat_watcher;
 to read that byte, and in the callback for the read end, you would call
 C<eio_poll>.
 You don't have to take special care in the case C<eio_poll> doesn't handle
 all requests, as the done callback will not be invoked, so the event loop
-will still signal readyness for the pipe until I<all> results have been
+will still signal readiness for the pipe until I<all> results have been
 processed.
 =head1 HIGH LEVEL REQUEST API
   }
   /* the first three arguments are passed to open(2) */
   /* the remaining are priority, callback and data */
   if (!eio_open ("/etc/passwd", O_RDONLY, 0, 0, file_open_done, 0))
-    abort (); /* something ent wrong, we will all die!!! */
+    abort (); /* something went wrong, we will all die!!! */
 Note that you additionally need to call C<eio_poll> when the C<want_cb>
 indicates that requests are ready to be processed.
 =head2 CANCELLING REQUESTS
 Sometimes the need for a request goes away before the request is
-finished. In that case, one can cancel the reqiest by a call to
+finished. In that case, one can cancel the request by a call to
 C<eio_cancel>:
 =over 4
 =item eio_cancel (eio_req *req)
-Cancel the request. If the request is currently executing it might still
+Cancel the request (and all its subrequests). If the request is currently
-continue to execute, and in other cases it might still take a while till
+executing it might still continue to execute, and in other cases it might
-the request is cancelled.
+still take a while till the request is cancelled.
 Even if cancelled, the finish callback will still be invoked - the
 callbacks of all cancellable requests need to check whether the request
 has been cancelled by calling C<EIO_CANCELLED (req)>:
   {
     if (EIO_CANCELLED (req))
       return 0;
   }
-In addition, cancelled requests will either have C<< req->result >> set to
+In addition, cancelled requests will I<either> have C<< req->result >>
-C<-1> and C<errno> to C<ECANCELED>, or otherwise they were successfully
+set to C<-1> and C<errno> to C<ECANCELED>, or I<otherwise> they were
-executed despite being cancelled (e.g. when they have already been
+successfully executed, despite being cancelled (e.g. when they have
-executed at the time they were cancelled).
+already been executed at the time they were cancelled).
+C<EIO_CANCELLED> is still true for requests that have successfully
+executed, as long as C<eio_cancel> was called on them at some point.
 =back
 =head2 AVAILABLE REQUESTS
       free (target);
     }
 =item eio_realpath  (const char *path, int pri, eio_cb cb, void *data)
-Similar to the realpath libc function, but unlike that one, result is
+Similar to the realpath libc function, but unlike that one, C<<
-C<-1> on failure and the length of the returned path in C<ptr2> (which is
+req->result >> is C<-1> on failure. On success, the result is the length
-not 0-terminated) - this is similar to readlink.
+of the returned path in C<ptr2> (which is I<NOT> 0-terminated) - this is
+similar to readlink.
 =item eio_stat      (const char *path, int pri, eio_cb cb, void *data)
 =item eio_lstat     (const char *path, int pri, eio_cb cb, void *data)
 =back
 =head3 READING DIRECTORIES
 Reading directories sounds simple, but can be rather demanding, especially
-if you want to do stuff such as traversing a diretcory hierarchy or
+if you want to do stuff such as traversing a directory hierarchy or
-processing all files in a directory. Libeio can assist thess complex tasks
+processing all files in a directory. Libeio can assist these complex tasks
 with it's C<eio_readdir> call.
 =over 4
 =item eio_readdir (const char *path, int flags, int pri, eio_cb cb, void *data)
 When this flag is specified, then the names will be returned in an order
 suitable for stat()'ing each one. That is, when you plan to stat()
 all files in the given directory, then the returned order will likely
 be fastest.
-If both this flag and C<EIO_READDIR_DIRS_FIRST> are specified, then
+If both this flag and C<EIO_READDIR_DIRS_FIRST> are specified, then the
-the likely dirs come first, resulting in a less optimal stat order.
+likely directories come first, resulting in a less optimal stat order.
 =item EIO_READDIR_FOUND_UNKNOWN
 This flag should not be specified when calling C<eio_readdir>. Instead,
 it is being set by C<eio_readdir> (you can access the C<flags> via C<<
 req->int1 >>, when any of the C<type>'s found were C<EIO_DT_UNKNOWN>. The
-absense of this flag therefore indicates that all C<type>'s are known,
+absence of this flag therefore indicates that all C<type>'s are known,
 which can be used to speed up some algorithms.
 A typical use case would be to identify all subdirectories within a
 directory - you would ask C<eio_readdir> for C<EIO_READDIR_DIRS_FIRST>. If
 then this flag is I<NOT> set, then all the entries at the beginning of the
 as calling C<fdatasync>.
 Flags can be any combination of C<EIO_SYNC_FILE_RANGE_WAIT_BEFORE>,
 C<EIO_SYNC_FILE_RANGE_WRITE> and C<EIO_SYNC_FILE_RANGE_WAIT_AFTER>.
+=item eio_fallocate (int fd, int mode, off_t offset, off_t len, int pri, eio_cb cb, void *data)
+Calls C<fallocate> (note: I<NOT> C<posix_fallocate>!). If the syscall is
+missing, then it returns failure and sets C<errno> to C<ENOSYS>.
+The C<mode> argument can be C<0> (for behaviour similar to
+C<posix_fallocate>), or C<EIO_FALLOC_FL_KEEP_SIZE>, which keeps the size
+of the file unchanged (but still preallocates space beyond end of file).
 =back
 =head3 LIBEIO-SPECIFIC REQUESTS
 These requests are specific to libeio and do not correspond to any OS call.
   eio_custom (my_open, 0, my_open_done, "/etc/passwd");
 =item eio_busy (eio_tstamp delay, int pri, eio_cb cb, void *data)
-This is a a request that takes C<delay> seconds to execute, but otherwise
+This is a request that takes C<delay> seconds to execute, but otherwise
 does nothing - it simply puts one of the worker threads to sleep for this
 long.
 This request can be used to artificially increase load, e.g. for debugging
 or benchmarking reasons.
 There are two primary use cases for this: a) bundle many requests into a
 single, composite, request with a definite callback and the ability to
 cancel the whole request with its subrequests and b) limiting the number
 of "active" requests.
-Further below you will find more dicussion of these topics - first follows
+Further below you will find more discussion of these topics - first
-the reference section detailing the request generator and other methods.
+follows the reference section detailing the request generator and other
+methods.
 =over 4
 =item eio_req *grp = eio_grp (eio_cb cb, void *data)
-Creates, submits and returns a group request.
+Creates, submits and returns a group request. Note that it doesn't have a
+priority, unlike all other requests.
 =item eio_grp_add (eio_req *grp, eio_req *req)
 Adds a request to the request group.
 =item eio_grp_cancel (eio_req *grp)
 Cancels all requests I<in> the group, but I<not> the group request
-itself. You can cancel the group request via a normal C<eio_cancel> call.
+itself. You can cancel the group request I<and> all subrequests via a
+normal C<eio_cancel> call.
 =back
+=head4 GROUP REQUEST LIFETIME
+Left alone, a group request will instantly move to the pending state and
+will be finished at the next call of C<eio_poll>.
+The usefulness stems from the fact that, if a subrequest is added to a
+group I<before> a call to C<eio_poll>, via C<eio_grp_add>, then the group
+will not finish until all the subrequests have finished.
+So the usage cycle of a group request is like this: after it is created,
+you normally instantly add a subrequest. If none is added, the group
+request will finish on it's own. As long as subrequests are added before
+the group request is finished it will be kept from finishing, that is the
+callbacks of any subrequests can, in turn, add more requests to the group,
+and as long as any requests are active, the group request itself will not
+finish.
+=head4 CREATING COMPOSITE REQUESTS
+Imagine you wanted to create an C<eio_load> request that opens a file,
+reads it and closes it. This means it has to execute at least three eio
+requests, but for various reasons it might be nice if that request looked
+like any other eio request.
+This can be done with groups:
+=over 4
+=item 1) create the request object
+Create a group that contains all further requests. This is the request you
+can return as "the load request".
+=item 2) open the file, maybe
+Next, open the file with C<eio_open> and add the request to the group
+request and you are finished setting up the request.
+If, for some reason, you cannot C<eio_open> (path is a null ptr?) you
+can set C<< grp->result >> to C<-1> to signal an error and let the group
+request finish on its own.
+=item 3) open callback adds more requests
+In the open callback, if the open was not successful, copy C<<
+req->errorno >> to C<< grp->errorno >> and set C<< grp->errorno >> to
+C<-1> to signal an error.
+Otherwise, malloc some memory or so and issue a read request, adding the
+read request to the group.
+=item 4) continue issuing requests till finished
+In the real callback, check for errors and possibly continue with
+C<eio_close> or any other eio request in the same way.
+As soon as no new requests are added the group request will finish. Make
+sure you I<always> set C<< grp->result >> to some sensible value.
+=back
+=head4 REQUEST LIMITING
 #TODO
-/*****************************************************************************/
-/* groups */
-eio_req *eio_grp       (eio_cb cb, void *data);
-void eio_grp_feed      (eio_req *grp, void (*feed)(eio_req *req), int limit);
 void eio_grp_limit     (eio_req *grp, int limit);
-void eio_grp_cancel    (eio_req *grp); /* cancels all sub requests but not the group */
 =back
 for example, in interactive programs, you might want to limit this time to
 C<0.01> seconds or so.
 Note that:
+=over 4
-a) libeio doesn't know how long your request callbacks take, so the time
+=item a) libeio doesn't know how long your request callbacks take, so the
-spent in C<eio_poll> is up to one callback invocation longer then this
+time spent in C<eio_poll> is up to one callback invocation longer then
-interval.
+this interval.
-b) this is implemented by calling C<gettimeofday> after each request,
+=item b) this is implemented by calling C<gettimeofday> after each
-which can be costly.
+request, which can be costly.
-c) at least one request will be handled.
+=item c) at least one request will be handled.
+=back
 =item eio_set_max_poll_reqs (unsigned int nreqs)
 When C<nreqs> is non-zero, then C<eio_poll> will not handle more than
 C<nreqs> requests per invocation. This is a less costly way to limit the

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing libeio/eio.pod (file contents): Revision 1.17 by root, Tue Jul 5 18:59:28 2011 UTC vs. Revision 1.24 by sf-exg, Thu Jul 14 08:51:29 2011 UTC

Diff Legend

Comparing libeio/eio.pod (file contents):
Revision 1.17 by root, Tue Jul 5 18:59:28 2011 UTC vs.
Revision 1.24 by sf-exg, Thu Jul 14 08:51:29 2011 UTC