GLOBUS_XIO

1
GLOBUS_XIO
2
Architeture
Plugins
3
User API

• posix like api
• open, close, read, write, seek, flush, opendir,
  closedir, readdir, rewinddir, mkdir, rmdir,
  rename, stat, chmod, chown
• Uses handles and attributes instead of file
  descriptors and flags.
• File names are URLs
• Asynchronous and synchronous functions
• A nonblocking function with a callback for all io
  blocking functions.

4
Plugins

• The majority of the work is done by plugins
• Plugins are responsible for all file access and
  data transporting.
• The api does error checking and state book
  keeping only.
• Easy to add new protocols to existing
  applications
• All applications written to the globus_xio api
  can use any plugin.
• To add a new protocol, write a new plugin.
• URL based
• Each plugin is associated with the scheme portion
  of a url. file/tmp/foo will be associated with
  the "file" plugin.
• When a url is opened the correct plugin is found.

5
Plugins Interface

• Thin layer away from user API
• Open, close, read, write, flush
• API hides some book keeping issues and provides
  "helper" functions.
• Blocking or nonblocking calls are exposed to the
  plugin author.
• Blocking can be implemented in terms of
  nonblocking, but is not required.
• Does not require the author to implement 2
  functions.
• This provides oppertunities for optimization

6
Operation
Attr owns n number of plugins
Handle is associate with an attr when a url is
opened
The plugin for the handle is selected based on
the url All io operations performed on the handle
are routed to the selected plugin.
7
Re-entrant / "stackable"

• globus_xio is reentrant
• Plugins can be implemented by using the
  globus_xio library
• Ex A ftp plugin could be implemented by using
  globus_xio with a tcp plugin
• Only a single operation can be registered on any
  given handle at 1 time