James Carlson wrote: > Darren J Moffat wrote: > o This interface allows the appointment of a door server thread >> creation function on a per-door basis, something that >> is not possible with the existing door_create(3C) and >> door_server_create(3C) interfaces. This facility is the >> primary reason for the introduction of this interface - without >> it the use of door servers in general-purpose system libraries >> is problematic since the thread creation function is shared >> with the application which may itself offer a door server. > > This hints at it, but could you provide a more concrete usage case? I > assume there's a consumer waiting for this, and details about the usage > may be interesting.
The first consumer will be an addition the the GPEC (general-purpose event channels) interface: sysevent_evc_xsubscribe will use door_xcreate to allow full control over the delivery threads that GPEC uses in event callbacks. That ARC case will be along soon. The extended subscription interface sysevent_evc_xsubscribe will be used in a new Committed interface libfmevent which will allow a process to subscribe to FMA protocol events (of which there will be some new ones soon that describe things like SMF state transitions). This libfmevent interface will be usable directly, and also via scripting language bindings (e.g., a Perl script can subscribe to events). In both cases we do not have control over what other doors usage there may be in the process that is using libfmevent - so we cannot use the global door_server_create(3C) interface etc. Fishworks has also has problems with the global nature of door_server_create. In that case, being an appliance, they do have control over the exact context and so with some hackery were able to workaround this restriction (and a few others in the doors API). The door_xcreate interface has been designed to be of use in eliminating that hackery, too. Gavin
