resource manager - dynamic pathname space

At a loss here:

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

On Thu, 17 May 2001 12:11:17 -0400, “Mike Kadour”
<mjkadour@uwaterloo.ca> wrote:

At a loss here:

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

On Fri, 18 May 2001 12:11:10 GMT, ako@box43.gnet.pl (Andrzej Kocon)
wrote:

On Thu, 17 May 2001 12:11:17 -0400, “Mike Kadour”
mjkadour@uwaterloo.ca> > wrote:

At a loss here:

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

Mike Kadour <mjkadour@uwaterloo.ca> wrote:

At a loss here:

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).

You might want to look at the mount example at

http://staff.qnx.com/~thomasf/nto.html

Otherwise post your code for all to comment on.

Thomas

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf

Thanks for the responses…

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