I’m having a design question. I want to implement CSP[1] like processes within QNX. CSP uses multiple rendezvous channels in order to communicate with other CSP like processes.
Currently I’m using resource managers to demonstrate this CSP concept in QNX. However, the only reason I’m using this is that it gets me an entry in the file system and I’m able to open the FD and use it as a coid. This way its relatively easy to implement distributed approach.
No for my question, first of all I want a CSP process may have multiple channels, I can do a switch on the incoming message but I’d rather have something like /csp/A/channel1 /csp/A/channel2 etc…etc I’ve read something about resource managers and adding extra mount points but it seems to bloated for what I want. (io funcs attributes etc)
Does anyone know a more light way method to achieve this? I only what the coid to appear in a directory like structure. I came across a post of mario that has a similar approach, but I think he uses the resource manager for this, mario? Care to elaborate?
While I’m add it; is it possible share one coid among several process? I would like to implement a one-to-many channel, or should I write yet another resource manager (or similar) that implements this behavior?
I don’t know why are worrying about additional “mount points”. It is possible to manage a more dynamic/flexible directory like structure, but it takes more work. Unless you have hundreds of your “channels” then this probably isn’t worth the trouble.
If you want to know whether you can share a coid among several processes, you need to take a look at the system architecture, as your question really doesn’t make any sense. Maybe what you seek is a thread pool?
I don’t know if this will be helpful, but a quick browse of your CSP wikipedia link reminded me a little of the language Erlanger. Porting Erlanger to QNX up to a certain point is quite easy.
I dont want to get in to porting, I want (and must) to use the CSP. And its not a worry its something that I want, because if the coid’s are there in a directory it makes it more easy for me to connect to the fd’s when i’m doing distributed I/O.
For instance a CSP process might have 5 data channels. These data channels all ‘provide’ a different interconnect. From the 5 data channels 3 channels are connecteted to process B and 1 to C and the last one to E. (in example) This might not be the best example, but what I simply need are multiple channels that are easy to resolve.
I do not need a thread pool since thread pools all do the same thing. Thats not what I need.
ChannelCreate(0);
ChannelCreate(1);
ChannelCreate(2);
ChannelCreate(3); —> how can I export these to a file descriptor under processname/coid
Does that have anything to do with threads? If so; I realy need to re check the docs
All threads in a process have access to COID, and can be woken from being Receive blocked on the COID. A thread pool simplifies this. Separate processes cannot use the same COID, and it would not make sense for them to.
Its the same process but it just has multiple COID’s – each COID gets handled by an other thread. The threads them self contain different logic. (otherwise I would have used a thread pool) So if I use the terminologies of QNX, a processes is like a thread container, the container has multiple threads → I want to have multiple COID’s each for each thread.
Can this be done? Or does it not make sense it all?
When implementing a resource manager that needs to handle multiple devices (e.g. channel1, channel2, …) you have two possibilities:
register each single device:
→ resmgr_attach(…, “/csp/A/channel1”, …, 0, …)
register the “root directory” of the devices:
→ resmgr_attach(…, “/csp/A”, …, _RESMGR_FLAG_DIR, …)
With (1) your devices are handled automagically by the resource manager framework - it’s a very easy and fast to implement. With (2) there is more work to do: you have to handle the sub-path (channel1, channel2, …) in your open handler to assign the right device and you have to handle the read of your resource manager’s directory.
There is an excellent tutorial “Writing a Resource Manager” in the documentation. You will find more information on this topic in the section “Filesystem resource managers”.
Filesystem resource managers are not “bloated” - quite the contrary: they are maybe more light way than resource managers that are attaching multiple devices, as every call of resmgr_attach() results in an additional entry in a table managed by the process manager (this table is looked up every time when opening a device). I would avoid to add hundreds of this entries as this might slow down the opening of devices on your system.
Slowing down the opening of a device is not a real concern I think. Reason being: 1) fd’s that are opened are a fixed number. 2) the system is distributed.
I’ll go for the first method you suggested. I also read the tutorial and indeed its a good one, I was just wondering, that I did not want to set attributes for io_func and io_connect etc for each of the devices in the csp file system entry.I guess its okay to use the same structure for multiple different entries, even more so because all I realy need is a entry in the file system so I can open it and use the fd as coid.
yes, you can use the same io_funcs and connect_funcs for each device in your resource manager as the functionality of all devices is the same. But every device must have it’s own iofunc_attr_t handle.
