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]
