Dennis Windisch wrote: > Is there a realtime equivalent to the normal select(...) function?
As Hans-Peter correctly remarked: no. The original plan was to create a select/poll framework at RTDM level so that driver writers could add the required support in a unified way. That would still be possible, but it requires some significant work. The problem about poll/select, specifically for RT environments, is that a) it needs some effort to avoid dynamic memory allocation (like Linux does for select), and b) it is a rather inefficient way to demultiplex incoming data streams. select/poll only informs you about some events, but requires a lot of setup/cleanup for this. And then you still need to call some other function to actually retrieve potential data or submit new. Given these problems and the required effort to solve them, and when furthermore considering the few *hard RT* applications actually requiring such a feature, I now doubt that it is really worth all the work on RTDM and the drivers. Anyone willing to prove me wrong in this regard by just doing it is welcome, really! > I have multiple clients sending data to a single server and therefore I > need a select(...) function. I guess you also mean that the clients are sending to different ports. Is there no way to direct the messages to a single port and demultiplex at application level? Are the messages undistinguishable when they would arrive on the same socket? > > I've written so far a simple program (not RT) doing this, using the > select(...) function. When I ported this program to RT, I just tried and > added a _rt suffix to select and as result I'm getting a linker error > (undefined reference to 'select_rt'). > > Since I've read in the forum threads about having or not having a > select_rt(...) function I'm now curious to know if there is a select_rt > in RTnet or not. Or have I just "forgotten" to link a file? (currently > I've only included rtnet.h, including rtnet_sys.h getting me a lot of > errors). > > Or if there's no select_rt(...) available, what alternatives do I have to > accomplish the scenario written above (multiple clients sending date to > single server - without using RTmac/TDMA)? > The last resort is to create multiple threads and synchronise them when required. Admittedly, this /can/ be even more inefficient than a potential select/poll RT-variant (but it allows prioritisation). So, I would rather try to avoid scenarios where events can arrive in an unordered way on multiple channels for a single consumer. Jan
signature.asc
Description: OpenPGP digital signature
