pansuriya.amit

Dear Sir,
i m going to use NP5610-16 moxa device for multiport serial communication.
i m using fedora-core 6 o.s.
after installation it will detect serial ports as /dev/ttyr0,/dev/ttyr1 .....etc
now i want to write application which monitor all serial ports and received data from particular serial ports.
after that it send data on particular port.
its ok i understand this concept.
but i confuse that what programming approach i have to use to monitor multiport serial ports.
i have to fire 16 diff threads for each port or what
plz help me to sort out this issue
please also guide me that which is the best approach i have to use for this
Regards,
Amit

Salem

Using threads is one way, providing each thread only accesses a single port, and has only thread-local data.

But if there is any shared data, say reading from one port and writing to another, then threads will be harmful to your code. Debugging massively threaded code which doesn't have a solid design and poor use of say semaphores to protect access to shared data will be a nightmare.

http://www.linuxmanpages.com/man2/select_tut.2.php
http://www.linuxmanpages.com/man2/select.2.php
The select() system call offers a way to monitor many file descriptors at the same time.
Essentially, when something interesting happens, select() returns, and then you can deal with it.

__________________
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.

pansuriya.amit

Sir,
i m going to use 32 com port.
if i create two thread for each serial port(one thread for read and one for write), then there are total 64 threads are required.
is it good design .
actually there is one server pc and i use 32 port serial device.
now i want to read data from particular portnumber after that server decide on what port number i have to transfer data
plz suggest me whats the best design for multiport serial communication
amit

Salem

I wouldn't regard so many threads as being good design, no.

__________________
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.

matsp

What is a good design in one case, is quite often a bad design in another situation - and the right answer is always "what works well for what you want to do". I agree with Salem, that is' unlikely that having 64 threads is a good design - it MAY be if all ports are almost always used, then that's a good way to do it. But not if the common case is that most ports are "not in use".

So, you have 32 serial ports, one of which is sending stuff to your application, to then send something out on another port.

I would think that you could create a thread (or pair of threads if that's a better fit) based on the request to send data. That way you don't have several dozen threads "laying about doing nothing". When the data transfer is finished, the thread kills itself (or sends a message back to the controller thread to "ask to be killed").

If you don't know which port data is coming in, use select() to listen to several serial ports at once, and then create threads as necessary.

The "create thread as necessary" assumes that you're actually sending data for some time on the port choosen, rather than a few bytes - if it's a few bytes, it's probably better to just do all of it in a single thread.

--
Mats