2
0

mono_handle_d 3.2 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798
  1. =pod
  2. =head1 Internal design document for the mono_handle_d
  3. This document is designed to hold the design of the mono_handle_d and
  4. not as an api reference.
  5. =head2 Primary goal and purpose
  6. The mono_handle_d is a process which takes care of the (de)allocation
  7. of scratch shared memory and handles (of files, threads, mutexes,
  8. sockets etc. see L<WapiHandleType>) and refcounts of the
  9. filehandles. It is designed to be run by a user and to be fast, thus
  10. minimal error checking on input is done and will most likely crash if
  11. given a faulty package. No effort has been, or should be, made to have
  12. the daemon talking to machine of different endianness/size of int.
  13. =head2 How to start the daemon
  14. To start the daemon you either run the mono_handle_d executable or try
  15. to attach to the shared memory segment via L<_wapi_shm_attach> which
  16. will start a daemon if one does not exist.
  17. =head1 Internal details
  18. The daemon works by opening a socket and listening to clients. These
  19. clients send packages over the socket complying to L<struct
  20. WapiHandleRequest>.
  21. =head2 Possible requests
  22. =over
  23. =item WapiHandleRequest_New
  24. Find a handle in the shared memory segment that is free and allocate
  25. it to the specified type. To destroy use
  26. L</WapiHandleRequest_Close>. A L<WapiHandleResponse> with
  27. .type=WapiHandleResponseType_New will be sent back with .u.new.handle
  28. set to the handle that was allocated. .u.new.type is the type that was
  29. requested.
  30. =item WapiHandleRequestType_Open
  31. Increase the ref count of an already created handle. A
  32. L<WapiHandleResponse> with .type=WapiHandleResponseType_Open will be sent
  33. back with .u.new.handle set to the handle, .u.new.type is set to the
  34. type of handle this is.
  35. =item WapiHandleRequestType_Close
  36. Decrease the ref count of an already created handle. A
  37. L<WapiHandleResponse> with .type=WapiHandleResponseType_Close will be
  38. sent back with .u.close.destroy set to TRUE if ref count for this
  39. client reached 0.
  40. =item WapiHandleRequestType_Scratch
  41. Allocate a shared memory area of size .u.scratch.length in bytes. A
  42. L<WapiHandleResponse> with .type=WapiHandleResponseType_Scratch will be
  43. sent back with .u.scratch.idx set to the index into the shared
  44. memory's scratch area where to memory begins. (works just like
  45. malloc(3))
  46. =item WapiHandleRequestType_Scratch
  47. Deallocate a shared memory area, this must have been allocated before
  48. deallocating. A L<WapiHandleResponse> with
  49. .type=WapiHandleResponseType_ScratchFree will be sent back (works just
  50. like free(3))
  51. =back
  52. =head1 Why a daemon
  53. From an email:
  54. Dennis: I just have one question about the daemon... Why does it
  55. exist? Isn't it better performancewise to just protect the shared area
  56. with a mutex when allocation a new handle/shared mem segment or
  57. changing refcnt? It will however be a less resilient to clients that
  58. crash (the deamon cleans up ref'd handles if socket closes)
  59. Dick: It's precisely because with a mutex the shared memory segment
  60. can be left in a locked state. Also, it's not so easy to clean up
  61. shared memory without it (you can't just mark it deleted when creating
  62. it, because you can't attach any more readers to the same segment
  63. after that). I did some minimal performance testing, and I don't
  64. think the daemon is particularly slow.
  65. =head1 Authors
  66. Documentaion: Dennis Haney
  67. Implementation: Dick Porter
  68. =cut