This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Vte pty


Roland, I'm assuming that you intended to send this To: Chris? There's nothing here I don't already know.

Roland McGrath wrote:
I always prefer fine-grained modularity, myself.  What vte per se can do is
just create a terminal widget given a pty master fd.  So it seems proper to
me that libvte-java do just that.  The only thing it needs to do as far as
pty setup is to make sure the TIOCSWINSZ ioctl is done on the master, which
means call _vte_pty_set_size.  If the new vte entry point taking a pty fd
does not already do this, then a call to vte_terminal_set_size will.
(Probably it's best for the vte entry point to do this automatically.)

I don't know a thing about Java, but surely there is already some simple
way to make a Java stream that talks to an existing fd.  I can't imagine
that people writing C/C++ code to work with Java don't do this all the
time.  It seems perfectly reasonable that Java code itself not deal with
file descriptors as ints at all--that way it can be made impossible for
Java code to leak open fds the way C code can.  But JNI, or whatever the
C/C++ hooey for talking to Java is, must have ways to do this.  How else
would the Java runtime interfaces for networking et al be implemented under
the hood?

Creating the pty is a separable job, that will at some point be useful to
do for reasons other than to hand it to vte.  All forkpty does is call
openpty, and then fork and use login_tty in the child.  openpty is a
reasonable thing to call, but all it does is a simple sequence of standard
calls to create the master side and get the file name of the slave side,
and then it just opens it with a normal open call.  It makes sense to me
that Frysk should somewhere have a utility function with a Java interface
to just open a new master pty and yield the name of its slave side.

If it's as sensible as it should be to create a Java stream from an fd in a
native method, and to find the fd again from a native method called on the
stream, then returning a Java stream on the master fd is probably the
natural way for the pty creation method to work.  For vte, the stream's
only purpose would be to pass it to the vte code that takes over its fd and
then you wouldn't want the stream to live any longer.  For other kinds of
uses, a Java stream to do io to the master pty fd is useful directly.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]