I’ve written a resource manager that begins with a single device in the
pathname space (resmgr_attach’ed). After certain conditions occur I want to
add a second device while the resource manger is still running. While my
first thread is blocked with dispatch_block, a second thread (same process)
does another resmgr_attach to the original dpp. The new resmgr_attach uses
a new attributes structure (new inode) and a new path. Despite the second
device appearing in the path name space, my dispatch_handler does not handle
the connect messages that arrive from opens to this new device. The
dispatch_block unblocks, and the dispatch_handler does nothing. I even
perform a dispatch_context_free and dispatch_context_alloc to ensure my ctp
is aware of the new resmgr_attach.
Any suggestions or comments?
Thanks,
Mike Kadour
Electrical Engineering
University of Waterloo
I’ve written a resource manager that begins with a single device in the
pathname space (resmgr_attach’ed). After certain conditions occur I want to
add a second device while the resource manger is still running. While my
first thread is blocked with dispatch_block, a second thread (same process)
does another resmgr_attach to the original dpp. The new resmgr_attach uses
a new attributes structure (new inode) and a new path. Despite the second
device appearing in the path name space, my dispatch_handler does not handle
the connect messages that arrive from opens to this new device. The
dispatch_block unblocks, and the dispatch_handler does nothing. I even
perform a dispatch_context_free and dispatch_context_alloc to ensure my ctp
is aware of the new resmgr_attach.
Any suggestions or comments?
Shouldn’t there be separate dpp’s and ctp’s for the two
channels?
ako
Thanks,
Mike Kadour
Electrical Engineering
University of Waterloo
I’ve written a resource manager that begins with a single device in the
pathname space (resmgr_attach’ed). After certain conditions occur I want to
add a second device while the resource manger is still running. While my
first thread is blocked with dispatch_block, a second thread (same process)
does another resmgr_attach to the original dpp. The new resmgr_attach uses
a new attributes structure (new inode) and a new path. Despite the second
device appearing in the path name space, my dispatch_handler does not handle
the connect messages that arrive from opens to this new device. The
dispatch_block unblocks, and the dispatch_handler does nothing. I even
perform a dispatch_context_free and dispatch_context_alloc to ensure my ctp
is aware of the new resmgr_attach.
Any suggestions or comments?
Shouldn’t there be separate dpp’s and ctp’s for the two
channels?
…and separate dispatch_block()/_handler(), each set serving
separate paths?
ako
Thanks,
Mike Kadour
Electrical Engineering
University of Waterloo
I’ve written a resource manager that begins with a single device in the
pathname space (resmgr_attach’ed). After certain conditions occur I want to
add a second device while the resource manger is still running. While my
first thread is blocked with dispatch_block, a second thread (same process)
does another resmgr_attach to the original dpp. The new resmgr_attach uses
a new attributes structure (new inode) and a new path. Despite the second
device appearing in the path name space, my dispatch_handler does not handle
the connect messages that arrive from opens to this new device. The
dispatch_block unblocks, and the dispatch_handler does nothing. I even
perform a dispatch_context_free and dispatch_context_alloc to ensure my ctp
is aware of the new resmgr_attach.
Any suggestions or comments?
Tough to comment without some code. I can assure you that
I have resource managers sharing the same dispatch pointer
and thread pool with differing attributes (and being serviced).
After further debugging it turns out that my IO and connect function tables
were not accessable by the file that was trying to resmgr_attach(). (for
those who will make my mistake: static global variables have file scope)
And for those wishing to dynamically modify the path their resource manager
handles, it is as simple as creating a new attributes structure for each
device and performing a resmgr_attach - very powerful, and damn slick.
Cheers,
Mike Kadour
Electrical Engineering
University of Waterloo