1. 10 Mar, 2014 1 commit
  2. 07 Mar, 2014 4 commits
  3. 06 Mar, 2014 10 commits
  4. 05 Mar, 2014 3 commits
    • Steven Murray's avatar
      06610421
    • Steven Murray's avatar
      Added a concrete sub-class of castor::io::PollReactor · 4b4fc495
      Steven Murray authored
      This concrete implementation will hopefully be generic enough
      to be shared between the future tape server and remote media
      changer daemons.
      4b4fc495
    • Steven Murray's avatar
      Added the PollReactor and PollEventHandler classes to castor::io · 50e3c9e9
      Steven Murray authored
      The future tape server and remote media changer daemons will be single
      threaded.  They will therefore most probably use the poll() system call
      to handle multiple simultaneous I/O requests using a single thread. The
      Reactor architecture pattern described in the following book is one way
      to use poll() in a object-oriented way.  The PollReactor and
      PollEventHandler classes contribute towards implementing this pattern.
      
          Pattern-Oriented Software Architecture Volume 2
          Patterns for Concurrent and Networked Objects
          Authors: Schmidt, Stal, Rohnert and Buschmann
          Publication date: 2000
          ISBN 0-471-60695-2
      50e3c9e9
  5. 04 Mar, 2014 9 commits
  6. 03 Mar, 2014 4 commits
  7. 01 Mar, 2014 1 commit
  8. 28 Feb, 2014 4 commits
  9. 27 Feb, 2014 2 commits
    • Steven Murray's avatar
      I have fixed castor::io::unmarshalUnit64(). · d1c030fe
      Steven Murray authored
      The castor::io::unmarshalUint64() method was not unmarshalling a 64-bit
      integer in the same was as the legacy code of h/marshall.h.
      
      The legacy code was treating a 64-bit integer as two 32-bit integers. It
      would first unmarshall a 32-bit integer representing the lower powers of 2
      and then marshall a 32-bit integer representing the higher powers of 2.
      
      The castor::io::unmarshalUint64() method was incorrectly treating a 64-bit
      integer as a whole by simply unmarshalling the whole 8 byte block of
      memory in reverse byte order.
      d1c030fe
    • Steven Murray's avatar
      I have fixed castor::io::marshalUnit64(). · e8379fff
      Steven Murray authored
      The castor::io::marshalUint64() was not marshalling a 64-bit integer in the
      same was as the legacy code of h/marshall.h.
      
      The legacy code was treating a 64-bit integer as two 32-bit integers. It
      would first marshall a 32-bit iinteger representing the lower powers of 2
      and then marshall a 32-bit integer representing the higher powers of 2.
      
      The castor::io::marshalUint64() method was incorrectly treating a 64-bit
      integer as a whole by simply marshalling the whole 8 byte block of
      memory in reverse byte order.
      e8379fff
  10. 26 Feb, 2014 2 commits
    • Steven Murray's avatar
      Removed the integer unmarshalling routines from castor::tape::legacymsg · f1bd6bf0
      Steven Murray authored
      The castor::tape::legacymsg package no longer needs to implement its own
      unmarshalling routines for integers because I have added such routines to
      castor::io.
      
      This commit is another step towards reducing the amount of utility code in
      the castor::tape package.
      f1bd6bf0
    • Steven Murray's avatar
      Replaced castor::io::unmarshallValue() by type specific marshall functions. · 1bac7a32
      Steven Murray authored
      The castor::io::unmarshallValue() function was incorrectly named.  The function
      was meant to be used soley for unmarshalling integer types and not any type.
      The function did not use ntohl() and ntohs() where they could have been used.
      CASTOR has to unmarshal 64-bit numbers and in this case it is true that the
      ntohl() family of functions is of no use, however for 16-bit and 32-bit numbers
      we should use them.
      1bac7a32