Re: Can 'graphics' be a file descriptor?

On 1/2/2025 5:35 PM, Lew Pitcher wrote:

On Thu, 02 Jan 2025 16:08:57 -0600, BGB wrote:
 

On 1/2/2025 3:06 PM, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Wed, 2025-01-01 at 14:33 -0800, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Wed, 2025-01-01 at 01:29 -0800, Keith Thompson wrote:

[...]

A file *descriptor* is a small integer referring to some file-like
entity, used with open/close/read/write.  There's no such thing in
standard C; it's a POSIX concept.

[...]

I would like to have opinions about the idea "graphics being a file
descriptor".  The implement is irrevent for the discussion. Some
imagination is required.

>
Why do you insist on referring to "file descriptors"?  That's a specific
term with a specific meaning: a small integer value used in POSIX I/O
(not in standard C).

>
I do not insist anything. I would just like to have an opinion on the idea
"graphics being a file descriptor".

>
So you insist on talking about "file descriptors".
>
Standard C doesn't have file descriptors.  Consider discussing this in
comp.unix.programmer.
>

>
It is also kinda moot...
>
If it were "integer handle" or even "integer value in the same numbering
space as file handles", I would be like "yeah, sure, whatever".
>
POSIX sockets also share the same numbering space, and some of the same
calls (Windows sockets do not, and many functions gain an WSA prefix and
changes to capitalization and similar).
>
>
>
If one wants it so that read/write/lseek/etc do something useful with
them, this is a different matter.
>
What happens then, does one represent a window as a BMP file or
something, which one writes to to update the contents?... This is likely
more overhead than is worthwhile.

 I refer you to the X11 specifications and example implementation found at
x.org
 X is a networked protocol that performs graphics functions. The network
communications used by X, on Unix and unix-like systems, accesses a socket
(which others have pointed out is, on Unix a "file descriptor"-like object)
 Granted, some dislike /how/ X uses network sockets for communication, and X
implementations (for Unixish systems) often provide alternatives such as
"unix domain sockets" and "shared memory" communications. Still, X has found
it "useful" to use these "file descriptor"-like objects to implement
"graphics" facilities.
 

Yeah, I already have a general idea how X works though...
The question there was more meant in the sense of, "What, exactly, is the OP expecting here?...".
Then giving one example of a possible interpretation of "How might the OP's question be turned into something that actually makes sense?...".

[snip]
 

Other methods, like sockets or local RPC, still likely make more sense.

 Oh, I'm glad that the techniques and technologies in use for over 30 years
gain your (apparently grudging) approval.
 

You misunderstand, I was not personally in favor of doing GUI via the filesystem, and in fact think doing so is probably a bad idea.
But, was more entertaining the OP's idea in a hypothetical sense (eg: In the form of "What if the OS window management were mapped to the filesystem?"; well, as opposed to something like Unix sockets).
In my own makeshift OS, I mostly did it instead via a sort of local RPC mechanism (interprocess RPC via a COM-like interface routed over the system-call mechanism).
Client process invokes a method, which invokes a system call, which is bounced over to the server task.
The server task basically exists in a thread that spins in an infinite loop trying to accept calls, process the requests, and passing control back to the caller (it then goes back to sleeping until another method call arrives).
Sockets would have been another possible option, but would have a latency that was at the whim of the OS scheduler.
Granted, it is possible that latency could be reduced on sockets if the caller writes to the socket and then immediately calls "usleep();" or similar, and if the OS has a mechanism to see that something was written to the socket and then immediately wake up any task that was waiting for input on that socket (say, via "poll()").
Well, as opposed to a "poll()" mechanism where it gets around to the task, sees that it is still waiting on IO, and leaves it sleeping. Granted, practical difference may not matter much if the system is mostly idle. But, latency would be negatively effected in this case if one has multiple running tasks which are effectively "eating the CPU".
But, for direct task-to-task control transfers, request/latency is not as significantly effected by the existence of "CPU eater" processes, ...
Decided to leave out going into the whole thing of process scheduling and trying to maintain semi-correct event timing (say, if one has processes that are supposed to wake/run at specific times; and it is "generally kinda bad" if the OS scheduler fails to wake the process when it was scheduled to be woken up, *).
*: Say, for updating step/direction pins on a stepper driver or updates for 1-2ms Servo-PWM pulses, ... Where the hardware may misbehave if these signals are not updated at the correct times.
...

:-)