Email list hosting service & mailing list manager

Re: How attached are we to taking a port (or port/fd) as well as a filename? hga@xxxxxx (09 Aug 2019 12:52 UTC)
with- and without- tty mode procedures hga@xxxxxx (15 Aug 2019 14:44 UTC)
Re: with- and without- tty mode procedures John Cowan (15 Aug 2019 16:04 UTC)
Re: with- and without- tty mode procedures Lassi Kortela (15 Aug 2019 16:15 UTC)
Re: with- and without- tty mode procedures hga@xxxxxx (15 Aug 2019 16:38 UTC)
Re: with- and without- tty mode procedures John Cowan (15 Aug 2019 17:11 UTC)
Re: with- and without- tty mode procedures hga@xxxxxx (20 Aug 2019 12:53 UTC)
Re: with- and without- tty mode procedures John Cowan (21 Aug 2019 22:51 UTC)
Re: with- and without- tty mode procedures hga@xxxxxx (22 Aug 2019 00:47 UTC)
(missing)
Re: with- and without- tty mode procedures hga@xxxxxx (24 Aug 2019 21:14 UTC)

Re: How attached are we to taking a port (or port/fd) as well as a filename? hga@xxxxxx 09 Aug 2019 12:52 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Friday, August 09, 2019 2:42 AM

>> [ John: ]

>> I am now firmly of opinion that we should remove all the
>> process-related functions from SRFI 170 along the lines you
>> specified earlier, whatever we decide to do about processes in a
>> future SRFI. I have some general ideas, but they are stll
>> completely unformed.

> [ Agreement, and comments on adding polling/select I/O scope. ]

I'll work on that next, forwarding to the list anything where I'm not
sure.  Right now that includes dup->fdes, as I understand it, dup and
dup2 are only needed in the context of forking.

In 3.5 Process state, do we keep pid?  parent-pid goes, I think.

(priority which who) gets reduced to a no argument call of the current
process and the priority/process option.  For the sake of simplicity
in the SRFI, perhaps keep only one of set-priority or nice?

Do you ever want to send a signal to yourself??  Hmmm, you do if you
want to test your signal handling code in a standardized way.

In the TTY section, I gather none of open-control-tty,
become-session-leader and control-tty-file-name stay.

>>  (set-file-mode fname/port mode-bits)
>>  (set-file-owner fname/port uid)
>>  (set-file-group fname/port gid)
>>  (set-file-timespecs fname/port [access-timespec modify-timespec])

>> I say: Switch all these to filenames only. You shouldn't be changing
>> these things for a file whose identity you dont know

> The point of these syscalls (fchmod, fchown, fchdir, etc.) is to use
> them in situations where you opened a known file. Using the fd
> instead of the path prevents things like having a directory
> disappear from underneath you during the lifetime of the process if
> that directory's path is renamed.

That's a good argument, given how easy it is to add port or port/fd.

Let me ask explicitly, do we want these instances of filename/port to
become filename/port/fd?  Only adds a little more logic in argument
parsing, but every bit counts.  I think no, for I suspect it only
makes sense to convert to ports as soon as you surface back to Scheme
from any C/FFI code you might be writing.

> [ We agree truncate-file and file-info keep their port option. ]

>>  (tty-process-group/port/fname/)|
>>  (set-tty-process-group/port/fname process-group/)|

>> These go with the process stuff, so no need to decide yet (see above).

> Or with the TTY stuff.

Both, it's in the TTY section, but I gather only make sense in the
context of multiple processes, whereas line discipline stuff, however
we do it, belongs in this SRFI.  Will be moved.

> [...]

- Harold