| … | |
… | |
| 45 | Unlike the name component C<stamp> might indicate, it is also used for |
45 | Unlike the name component C<stamp> might indicate, it is also used for |
| 46 | time differences throughout libeio. |
46 | time differences throughout libeio. |
| 47 | |
47 | |
| 48 | =head2 FORK SUPPORT |
48 | =head2 FORK SUPPORT |
| 49 | |
49 | |
| 50 | Calling C<fork ()> is fully supported by this module - but you must not |
50 | Usage of pthreads in a program changes the semantics of fork |
| 51 | rely on this. It is currently implemented in these steps: |
51 | considerably. Specifically, only async-safe functions can be called after |
|
|
52 | fork. Libeio uses pthreads, so this applies, and makes using fork hard for |
|
|
53 | anything but relatively fork + exec uses. |
| 52 | |
54 | |
| 53 | 1. wait till all requests in "execute" state have been handled |
55 | This library only works in the process that initialised it: Forking is |
| 54 | (basically requests that are already handed over to the kernel). |
56 | fully supported, but using libeio in any other process than the one that |
| 55 | 2. fork |
57 | called C<eio_init> is not. |
| 56 | 3. in the parent, continue business as usual, done |
|
|
| 57 | 4. in the child, destroy all ready and pending requests and free the |
|
|
| 58 | memory used by the worker threads. This gives you a fully empty |
|
|
| 59 | libeio queue. |
|
|
| 60 | |
58 | |
| 61 | Note, however, since libeio does use threads, the above guarantee doesn't |
59 | You might get around by not I<using> libeio before (or after) forking in |
| 62 | cover your libc, for example, malloc and other libc functions are not |
60 | the parent, and using it in the child afterwards. You could also try to |
| 63 | fork-safe, so there is very little you can do after a fork, and in fact, |
61 | call the L<eio_init> function again in the child, which will brutally |
| 64 | the above might crash, and thus change. |
62 | reinitialise all data structures, which isn't POSIX conformant, but |
|
|
63 | typically works. |
|
|
64 | |
|
|
65 | Otherwise, the only recommendation you should follow is: treat fork code |
|
|
66 | the same way you treat signal handlers, and only ever call C<eio_init> in |
|
|
67 | the process that uses it, and only once ever. |
| 65 | |
68 | |
| 66 | =head1 INITIALISATION/INTEGRATION |
69 | =head1 INITIALISATION/INTEGRATION |
| 67 | |
70 | |
| 68 | Before you can call any eio functions you first have to initialise the |
71 | Before you can call any eio functions you first have to initialise the |
| 69 | library. The library integrates into any event loop, but can also be used |
72 | library. The library integrates into any event loop, but can also be used |
| … | |
… | |
| 78 | This function initialises the library. On success it returns C<0>, on |
81 | This function initialises the library. On success it returns C<0>, on |
| 79 | failure it returns C<-1> and sets C<errno> appropriately. |
82 | failure it returns C<-1> and sets C<errno> appropriately. |
| 80 | |
83 | |
| 81 | It accepts two function pointers specifying callbacks as argument, both of |
84 | It accepts two function pointers specifying callbacks as argument, both of |
| 82 | which can be C<0>, in which case the callback isn't called. |
85 | which can be C<0>, in which case the callback isn't called. |
|
|
86 | |
|
|
87 | There is currently no way to change these callbacks later, or to |
|
|
88 | "uninitialise" the library again. |
| 83 | |
89 | |
| 84 | =item want_poll callback |
90 | =item want_poll callback |
| 85 | |
91 | |
| 86 | The C<want_poll> callback is invoked whenever libeio wants attention (i.e. |
92 | The C<want_poll> callback is invoked whenever libeio wants attention (i.e. |
| 87 | it wants to be polled by calling C<eio_poll>). It is "edge-triggered", |
93 | it wants to be polled by calling C<eio_poll>). It is "edge-triggered", |
