|
Home > Archive > Unix Programming > December 2006 > Serial port locking
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Serial port locking
|
|
| CptDondo 2006-12-13, 7:22 pm |
| I need a bit of advice:
I have a TCP to serial gateway that implements a specific protocol.
I've written it to sit behind inetd since it is simpler.
Here's my problem:
Inetd can launch multiple instances of the gateway, which is fine, as
there may be multiple serial devices.
My problem is that I am trying to figure out the best,
standards-compliant way to lock a serial device so that a new instance
cannot clobber an existing instance.
I've thought of locking using /var/lock files, but the problem there is
this:
Assume that the gateway process hangs with the port open. The protocol
I am using consists of a query-response-exit, which takes much less than
one second. So if there is a lock file that is older than, say, 30
seconds, I can kill the PID in the lockfile, remove the lockfile, and
take possession of the port.
Does this sound practical? The gateway is already threaded with a
watchdog thread on the serial port comm, so it should never hang.
However, these controllers have to run unattended for a year, with only
remote access, so I want to make the code as robust as possible.
Thanks,
--Yan
| |
| Robert Harris 2006-12-14, 8:08 am |
| CptDondo wrote:
> I need a bit of advice:
>
> I have a TCP to serial gateway that implements a specific protocol.
>
> I've written it to sit behind inetd since it is simpler.
>
> Here's my problem:
>
> Inetd can launch multiple instances of the gateway, which is fine, as
> there may be multiple serial devices.
>
> My problem is that I am trying to figure out the best,
> standards-compliant way to lock a serial device so that a new instance
> cannot clobber an existing instance.
Why not run one process or thread per serial device and have your daemon
connect to them?
Robert
> [snip]
> Thanks,
>
> --Yan
| |
| Captain Dondo 2006-12-14, 1:29 pm |
| V Thu, 14 Dec 2006 13:47:49 +0000, Robert Harris napsal(a):
> CptDondo wrote:
>
> Why not run one process or thread per serial device and have your daemon
> connect to them?
>
Because I don't know enough about sockets programming yet....
Seriously, I think a single threaded daemon is the best solution. this
owuld have some performance advantages as well; I won't have to parse an
XML config file very time. Unfortunately, this will be the first
threaded sockets-based daemon I will write.
Mostly I don't know how to handle the incoming connection if the backend
is busy, but I could use a good example for the whole thing. Is there a
good linux sockets reference somewhere?
Thanks,
--Yan
| |
| CptDondo 2006-12-14, 1:29 pm |
| Captain Dondo wrote:
>
> Because I don't know enough about sockets programming yet....
>
> Seriously, I think a single threaded daemon is the best solution.
OOPS! I think I meant "a single instance of a multi-threaded
daemon".... Otherwise it makes no sense.
--Yan
| |
| Robert Harris 2006-12-15, 7:34 am |
| Captain Dondo wrote:
> V Thu, 14 Dec 2006 13:47:49 +0000, Robert Harris napsal(a):
>
>
> Because I don't know enough about sockets programming yet....
>
> Seriously, I think a single threaded daemon is the best solution. this
> owuld have some performance advantages as well; I won't have to parse an
> XML config file very time. Unfortunately, this will be the first
> threaded sockets-based daemon I will write.
>
> Mostly I don't know how to handle the incoming connection if the backend
> is busy, but I could use a good example for the whole thing. Is there a
> good linux sockets reference somewhere?
The best reference is the classic book "Advanced programming in the Unix
Environment" by Stevens and Rago, now brought up to date. Or, just for
sockets etc., look at Beej's Guide to Network Programming:
<http://beej.us/guide/bgnet/> .
Robert
>
> Thanks,
>
> --Yan
|
|
|
|
|