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

Comparing libeio/eio.pod (file contents):
Revision 1.27 by root, Sun Jul 24 03:32:54 2011 UTC vs.
Revision 1.35 by root, Mon Aug 18 08:11:54 2014 UTC

 similar functions, as well as less rarely ones such as C<mknod>, C<futime>
 or C<readlink>.
 It also offers wrappers around C<sendfile> (Solaris, Linux, HP-UX and
 FreeBSD, with emulation on other platforms) and C<readahead> (Linux, with
-emulation elsewhere>).
+emulation elsewhere).
 The goal is to enable you to write fully non-blocking programs. For
 example, in a game server, you would not want to freeze for a few seconds
 just because the server is running a backup and you happen to call
 C<readdir>.
   {
     loop = EV_DEFAULT;
     ev_idle_init (&repeat_watcher, repeat);
     ev_async_init (&ready_watcher, ready);
-    ev_async_start (loop &watcher);
+    ev_async_start (loop, &watcher);
     eio_init (want_poll, 0);
   }
 For most other event loops, you would typically use a pipe - the event
 The C<void *data> member simply stores the value of the C<data> argument.
 =back
+Members not explicitly described as accessible must not be
+accessed. Specifically, there is no guarantee that any members will still
+have the value they had when the request was submitted.
 The return value of the callback is normally C<0>, which tells libeio to
 continue normally. If a callback returns a nonzero value, libeio will
 stop processing results (in C<eio_poll>) and will return the value to its
 caller.
-Memory areas passed to libeio must stay valid as long as a request
+Memory areas passed to libeio wrappers must stay valid as long as a
-executes, with the exception of paths, which are being copied
+request executes, with the exception of paths, which are being copied
 internally. Any memory libeio itself allocates will be freed after the
 finish callback has been called. If you want to manage all memory passed
 to libeio yourself you can use the low-level API.
 For example, to open a file, you could do this:
 Cancel the request (and all its subrequests). If the request is currently
 executing it might still continue to execute, and in other cases it might
 still take a while till the request is cancelled.
-Even if cancelled, the finish callback will still be invoked - the
+When cancelled, the finish callback will not be invoked.
-callbacks of all cancellable requests need to check whether the request
-has been cancelled by calling C<EIO_CANCELLED (req)>:
-  static int
-  my_eio_cb (eio_req *req)
-  {
-    if (EIO_CANCELLED (req))
-      return 0;
-  }
-In addition, cancelled requests will I<either> have C<< req->result >>
-set to C<-1> and C<errno> to C<ECANCELED>, or I<otherwise> they were
-successfully executed, despite being cancelled (e.g. when they have
-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
 =over 4
 =item eio_mtouch (void *addr, size_t length, int flags, int pri, eio_cb cb, void *data)
-Reads (C<flags == 0>) or modifies (C<flags == EIO_MT_MODIFY) the given
+Reads (C<flags == 0>) or modifies (C<flags == EIO_MT_MODIFY>) the given
 memory area, page-wise, that is, it reads (or reads and writes back) the
 first octet of every page that spans the memory area.
 This can be used to page in some mmapped file, or dirty some pages. Note
 that dirtying is an unlocked read-write access, so races can ensue when
 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
+req->errorno >> to C<< grp->errorno >> and set C<< grp->result >> 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
+In the read 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
+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
 void eio_grp_limit     (eio_req *grp, int limit);
-=back
 =head1 LOW LEVEL REQUEST API
 #TODO
 This symbol governs the stack size for each eio thread. Libeio itself
 was written to use very little stackspace, but when using C<EIO_CUSTOM>
 requests, you might want to increase this.
 If this symbol is undefined (the default) then libeio will use its default
-stack size (C<sizeof (void *) * 4096> currently). If it is defined, but
+stack size (C<sizeof (void *) * 4096> currently). In all other cases, the
-C<0>, then the default operating system stack size will be used. In all
-other cases, the value must be an expression that evaluates to the desired
+value must be an expression that evaluates to the desired stack size.
-stack size.
 =back
 =head1 PORTABILITY REQUIREMENTS

Diff Legend

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

Comparing libeio/eio.pod (file contents): Revision 1.27 by root, Sun Jul 24 03:32:54 2011 UTC vs. Revision 1.35 by root, Mon Aug 18 08:11:54 2014 UTC

Diff Legend

Comparing libeio/eio.pod (file contents):
Revision 1.27 by root, Sun Jul 24 03:32:54 2011 UTC vs.
Revision 1.35 by root, Mon Aug 18 08:11:54 2014 UTC