Prev: 067645 Answers to your Computer question! 63
Next: Processes' memory
From: Jef Driesen on 22 Jan 2010 09:24
Hi,

When I open a pseudo terminal, enable exclusive access and close the
file descriptor again:

fd = open (devname, ...);
ioctl (fd, TIOCEXCL, NULL);
close (fd);

And then try to open the same pseudo terminal again, it fails with the
error EBUSY. It seems that the exclusive flag persists after closing. Is
that the expected behavior? I did assume it would get cleared, because
now the terminal becomes locked forever.

Is the behavior with real serial ports the same?

When I clear the flag before closing, it works fine.

Thanks in advance?

Jef



From: David Schwartz on 22 Jan 2010 11:56
On Jan 22, 6:24 am, Jef Driesen <jefdrie...(a)hotmail.com.invalid>
wrote:

> When I open a pseudo terminal, enable exclusive access and close the
> file descriptor again:
>
> fd = open (devname, ...);
> ioctl (fd, TIOCEXCL, NULL);
> close (fd);
>
> And then try to open the same pseudo terminal again, it fails with the
> error EBUSY. It seems that the exclusive flag persists after closing. Is
> that the expected behavior? I did assume it would get cleared, because
> now the terminal becomes locked forever.

It is not locked forever. It is locked until the pty is no longer
used. Remember, a pty is *two* linked devices. If the other end is
still open, it's still the same instance and still holds properties
such as TIOCEXCL.

The point of TIOCEXCL is to prevent anyone else from stealing your pty
until you release it. With the other end of the pty still open, it's
still your pty and TIOCEXCL still has to keep other people from
getting to it until you disconnect it.

> Is the behavior with real serial ports the same?

Nope. Because there the device is fully released when the end is
closed.

DS
From: Jef Driesen on 24 Jan 2010 08:10
On 22/01/10 17:56, David Schwartz wrote:
> On Jan 22, 6:24 am, Jef Driesen<jefdrie...(a)hotmail.com.invalid>
> wrote:
>
>> When I open a pseudo terminal, enable exclusive access and close the
>> file descriptor again:
>>
>> fd = open (devname, ...);
>> ioctl (fd, TIOCEXCL, NULL);
>> close (fd);
>>
>> And then try to open the same pseudo terminal again, it fails with the
>> error EBUSY. It seems that the exclusive flag persists after closing. Is
>> that the expected behavior? I did assume it would get cleared, because
>> now the terminal becomes locked forever.
>
> It is not locked forever. It is locked until the pty is no longer
> used. Remember, a pty is *two* linked devices. If the other end is
> still open, it's still the same instance and still holds properties
> such as TIOCEXCL.

Makes sense. I assumed that each end has its own flags.

Anyway, the behavior is quite annoying in my case, because one end of
the pty is connected to a long running device simulator application
(socat), while the other end is a short lived app. And I want to be able
to run that app many times connecting to the same pty each time.

> The point of TIOCEXCL is to prevent anyone else from stealing your pty
> until you release it. With the other end of the pty still open, it's
> still your pty and TIOCEXCL still has to keep other people from
> getting to it until you disconnect it.

That's exactly why I would like to use TIOCEXCL, so nobody can
(accidentally) interfere with the communication. But in my case, I only
need the TIOCEXCL on one side of the pty. A partial solution is clearing
the TIOCEXCL again before closing the file descriptor, but that only
works well if the app terminates cleanly. And that doesn't always happen
during testing or debugging for instance.

>> Is the behavior with real serial ports the same?
>
> Nope. Because there the device is fully released when the end is
> closed.

Make sense because a serial port does not consist of the two pty parts.
From: David Schwartz on 24 Jan 2010 09:33
On Jan 24, 5:10 am, Jef Driesen <jefdrie...(a)hotmail.com.invalid>
wrote:

> That's exactly why I would like to use TIOCEXCL, so nobody can
> (accidentally) interfere with the communication. But in my case, I only
> need the TIOCEXCL on one side of the pty. A partial solution is clearing
> the TIOCEXCL again before closing the file descriptor, but that only
> works well if the app terminates cleanly. And that doesn't always happen
> during testing or debugging for instance.

Well, that obviously can't quite work that way. You can't say "I don't
want anyone to mess with my pty by accident, but I want my new process
to be able to get to it on purpose, even though they both might do it
precisely the same way."

There are a lot of possible solutions, but it can't happen "all by
itself". For example, you could have a root process whose sole purpose
is to manage access to the pty's and remove TIOCEXCL when appropriate
(or open the pty and hand the descriptor to you).

DS
From: Jef Driesen on 25 Jan 2010 04:58
On 24/01/2010 15:33, David Schwartz wrote:
> On Jan 24, 5:10 am, Jef Driesen<jefdrie...(a)hotmail.com.invalid>
> wrote:
>
>> That's exactly why I would like to use TIOCEXCL, so nobody can
>> (accidentally) interfere with the communication. But in my case, I only
>> need the TIOCEXCL on one side of the pty. A partial solution is clearing
>> the TIOCEXCL again before closing the file descriptor, but that only
>> works well if the app terminates cleanly. And that doesn't always happen
>> during testing or debugging for instance.
>
> Well, that obviously can't quite work that way. You can't say "I don't
> want anyone to mess with my pty by accident, but I want my new process
> to be able to get to it on purpose, even though they both might do it
> precisely the same way."

I don't see why that can't work. My app opens the pty and sets the
TIOCEXCL flag. Now any other process (including a new instance of my
app) is not allowed to access that pty anymore. That's exactly what I
want, thus so far no problem. But when my app has done its job, it
closes the pty again. At that point the pty should become available
again to other processes, regardless of whether that process is my app
or another one. There is no need to treat my app as special.
 |  Next  |  Last
Pages: 1 2 3 4
Prev: 067645 Answers to your Computer question! 63
Next: Processes' memory