> But if you are only listening on the same > type of socket, can't you map your incoming data on a single socket and > read from it (with timeout)?
Yeah! Tested and working. > See, this is about weighing the effort to establish and maintain the > required infrastructure in both RTDM and the drivers versus designing > the real-time application in a different way. I'm always open to learn > about scenarios where select-like mechanisms are such urgently required > that they would justify an effort in this direction. If a programmer has a few generic tools, a lot of solutions can be valid. You're right about the weight of the function, but it would be nice to have something that would trigger an incoming packet. Either way, this is a situation that select isn't mandatory :) Thanks for the help! Qua, 2006-11-29 às 15:59 +0100, Jan Kiszka escreveu: > Marcelo Coelho wrote: > > Hi list! > > > > > > Following the last email, I've decided to change the protocol used by > > the application and port it to use RTnet and RTAI. But now there is a > > relevant issue: How can I use a "select" mechanism with RTnet file > > descriptors? > > > > I'm using the select function to determine if a certain lan as received > > any information. If any of the 3 lans received something, then the > > application will process that data and act accordingly. > > > > So, is there some kind of mechanism to do this (besides waiting to read > > from a certain socket until a certain timeout :) )? > > > > select() itself is a fairly heavy-weighted mechanism that is, moreover, > tricky to implement in a deterministic manner (i.e. without the need for > dynamic memory allocations). RTnet, or better now RTDM, does not support > this kind signalling so far. But if you are only listening on the same > type of socket, can't you map your incoming data on a single socket and > read from it (with timeout)? > > See, this is about weighing the effort to establish and maintain the > required infrastructure in both RTDM and the drivers versus designing > the real-time application in a different way. I'm always open to learn > about scenarios where select-like mechanisms are such urgently required > that they would justify an effort in this direction. > > Jan > DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or without errors as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
