TODO.old

<<<<<<< HEAD
  - non-blocking dns resolution on a consumer thread.
    - may be able to do with fifo queue similar to interupts.
    - http://discuss.joelonsoftware.com/default.asp?joel.3.475011.13
=======
  - parser for config /etc/resolve?. just a simple closure. with regex. and or etc.

  - handle a single queue - based on a pipe - inside
      - handlers would have a predicate taking the messgae and returning
          whether they can handle the message
      - encode len, so that can always extract entire message, then pass to handler.
      - handler then co-exists with timeout
      - use for signals, - and would enable per signal handlers
      - also thread pool

    // No the way to do it, is to have another module entire.
    //   with one reader, that dequeues the message, and always rebinds itself
    //   and that maintains it's own handler set.
    //   that it delegates to (perhaps with predicates).
    //   this keeps it entirely out of the demux core.


  - non-blocking dns resolution on a consumer thread.
    - may be able to do with fifo queue similar to interupts.
    - http://discuss.joelonsoftware.com/default.asp?joel.3.475011.13

    - getaddrinfo_a() is async
    - http://stackoverflow.com/questions/22013421/non-blocking-network-address-resolution-gethostbyname-or-getaddrinfo

    - pool.c - push job onto pool with context and callback. then write pipe, with callback handler.
    POSIX.1 says that write(2)s of less than PIPE_BUF bytes must be atomic: the output data is written to the pipe as a contiguous sequence. Writes of more than PIPE_BUF bytes may be nonatomic: the kernel may interleave the data with data written by other processes. POSIX.1 requires PIPE_BUF to be at least 512 bytes. (On Linux, PIPE_BUF is 4096 bytes.)

>>>>>>> a41c7da07bae289eb65965f43332e0b6703a34a3
  - maybe rename Event to ReactorEvent or use reactor_event_t etc... becomes more complicated
  - maybe rename to use lowercase underscore t


from pool-docs

- when write the pipe, also write a message type. that way, we can use the pipe for more than
just signals.

- can use for signals, thread pool, dns etc.


- but issue with timeouts.  Unless we can use the regular handler mechanism...
    eg. bind a handler to watch for a signal of type 20. then if it times out,
    we get the regular behavior. 
    
    - it only means that some code needs to go directly into the reactor. to test
    whether the handler should be called.


- abstract the handler processing?
    - eg. a module that takes the message or queue fd, and the set of handlers and deals
    appropriately with them. letting timeouts and exceptions propagate?

--------
- would be nice to be able to handle different signal types in different handlers.  
    - needs to have regular timeout, and exception handling on the pipe fd.
    
--------

  Also potentially,   

#### NOTES

  - /blog - task esp8266, and control registers. screen, minicom, miniterm that I use
  this led, to writing a demux . handling of signals.