Re: modem control line checking - is polling the only way?

[Tom Glass]

What kind of time resolution are you needing?  I have an application
that monitors one serial port for incoming messages in an infinite
loop.  For some of the messages I initiate a child process that
communicates with a robot, voltmeter, and other hardware on two other
serial ports.  The parent process is then free to continue monitoring
the first port and is able to terminate the child process, if needed. 
My time resolution (including reading in and testing messages that can
be hundreds of bytes long) is about 1/2 to 1 second.  Probably I could
do better, but this meets my need nicely.

I realize this isn't exactly what you're talking about, but if it sounds
interesting I can send you code snippets.  

Personally, I think the fork solution is a pretty elegant way to handle
my problem and having had some experience with threads in windows makes
me very grateful to be working with processes in Linux.

Tom 

Craig Schlenter wrote:
 
 On Wed, May 17, 2000 at 04:16:24AM -0400, [EMAIL PROTECTED] wrote:
  Well, at a guess, you can wait for me to do a courtesy-call capable
  kernel, which may be a while, and a good while more for it to be
  accepted, or you can do it yourself, or you can solve the problem in a
  totally unexpected way.  Or you could just give over and fork(), but
  somehow I don't expect you will.
 
 I might just surprise you and use fork :) The fork method isn't elegant
 either but it beats polling IMHO. If I get it working (which will be
 after I sort out the rest of my software), I'll post an example to
 linux-serial.
 
 --C
 
 -
 To unsubscribe from this list: send the line "unsubscribe linux-serial" in
 the body of a message to [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]

Re: modem control line checking - is polling the only way?

[Craig Schlenter]

On Tue, May 16, 2000 at 04:06:50PM -0400, [EMAIL PROTECTED] wrote:
 It is a pity you couldn't be bothered to read linux-serial.  It is not a
 terribly busy list, but this very question has been asked and answered
 in the last week.  Maybe you can find some list archives somewhere.

It's not a question of "couldn't be bothered", but rather "didn't need to
before". I have subscribed now but please keep me on the cc list as I
expect it will take a while to process.

I did uncover some messages on dejanews yesterday before posting but
they pointed at ioctl's that were unhelpful when you want to do more
than just wait for control lines - I need to wait for input on a range
of fd's too. The messages I saw ended the thread with 'perhaps select
can be used but I don't know how' (or something like that). Is this the
thread you are referring to?

 Use the source, Luke.  linux/drivers/char/serial.c is not awfully big
 and has some nice comments.

Done that now. Nothing obvious to a non-kernel guru like me other than
the ioctl's to wait for changes but that puts a large dent in doing
anything else in the program unless I resort to using threads or some
form of ipc between processes that I'd much rather avoid. Is that the
only way or can select be used?

Thank you,

--Craig

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]