| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 94:13:22 |
| Calls: | 290 |
| Calls today: | 1 |
| Files: | 904 |
| Messages: | 76,378 |
On Fri, 03 Jan 2025 18:15:25 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
Paul <nospam@needed.invalid> writes:
On Thu, 1/2/2025 11:29 AM, Scott Lurndal wrote:
Why would you expect the link step to require a lot of
memory? The linker builds an elf executable from the contents
of ELF object files, one ELF section at a time. It doesn't
construct the entire ELF executable in memory before writing it out.
It's based on experience, not imagination.
I've built Thunderbird on both Windows and Linux.
It was the Windows build that left a bad taste.
Once you repeatedly have build failures during linking,
you are always looking for it.
Ah, well windows. You need not elaborate.
I've been fortunate to have never built software in a
microsoft environment (aside an optical jukebox driver
for NT3.51 once on a contract job - even then I did
all the editing on unix and just compiled and tested
on the windows box).
I did a Windows C++ job for a year. I still can't believe how complicated Visual Studio (2017 IIRC) made the most basic things such as setting library and include paths which were buried 2 or 3 levels down in some sub menu not to mention all the "project" BS which forced a certain structure on to your code filesystem layout which I didn't particularly want. Also the fact that console and GUI apps require a totally different project setup and boiler plate
code from the start is just mind boggling.
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation
on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
a bunch of them at DEC. They would instinctively turn away from Unix ways
of doing things, like forking multiple processes. So the systems they
created did not encourage such techniques.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Windows NT was masterminded by Dave Cutler ...
Is that Dave with a YouTube channel?
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation
on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible >for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
a bunch of them at DEC. They would instinctively turn away from Unix ways
of doing things, like forking multiple processes. So the systems they
created did not encourage such techniques.
On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation
on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible >>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of >>a bunch of them at DEC. They would instinctively turn away from Unix ways >>of doing things, like forking multiple processes. So the systems they >>created did not encourage such techniques.
Presumably VMS relied heavily on multithreading then like Windows or was a >process expected to everything itself sequentially?
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation
on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible >>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of >>a bunch of them at DEC. They would instinctively turn away from Unix ways >>of doing things, like forking multiple processes. So the systems they >>created did not encourage such techniques.
Presumably VMS relied heavily on multithreading then like Windows or was a >process expected to everything itself sequentially?
In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation >>>on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible >>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of >>>a bunch of them at DEC. They would instinctively turn away from Unix ways >>>of doing things, like forking multiple processes. So the systems they >>>created did not encourage such techniques.
Presumably VMS relied heavily on multithreading then like Windows or was a >>process expected to everything itself sequentially?
Many system services on VMS are asynchronous, and the system
architecture provides a mechanisms to signal completion; ASTs,
mailboxes, etc. Thus, many programs (not all) on VMS are
written in a callback/closure style.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation >>>>on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible >>>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of >>>>a bunch of them at DEC. They would instinctively turn away from Unix ways >>>>of doing things, like forking multiple processes. So the systems they >>>>created did not encourage such techniques.
Presumably VMS relied heavily on multithreading then like Windows or was a >>>process expected to everything itself sequentially?
Many system services on VMS are asynchronous, and the system
architecture provides a mechanisms to signal completion; ASTs,
mailboxes, etc. Thus, many programs (not all) on VMS are
written in a callback/closure style.
I imagine that could become complicated very quickly and presumably relies
on the OS providing the signalling mechanisms for everything you might
want to do - eg waiting for a socket connection (or whatever the decnet >equivalent was).
On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation >>>>on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible >>>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of >>>>a bunch of them at DEC. They would instinctively turn away from Unix ways >>>>of doing things, like forking multiple processes. So the systems they >>>>created did not encourage such techniques.
Presumably VMS relied heavily on multithreading then like Windows or was a >>>process expected to everything itself sequentially?
Many system services on VMS are asynchronous, and the system
architecture provides a mechanisms to signal completion; ASTs,
mailboxes, etc. Thus, many programs (not all) on VMS are
written in a callback/closure style.
I imagine that could become complicated very quickly and presumably relies
on the OS providing the signalling mechanisms for everything you might
want to do - eg waiting for a socket connection (or whatever the decnet >equivalent was).
In article <vlg4mb$1hi6d$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>>>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation >>>>>on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible
for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
a bunch of them at DEC. They would instinctively turn away from Unix ways >>>>>of doing things, like forking multiple processes. So the systems they >>>>>created did not encourage such techniques.
Presumably VMS relied heavily on multithreading then like Windows or was a >>>>process expected to everything itself sequentially?
Many system services on VMS are asynchronous, and the system
architecture provides a mechanisms to signal completion; ASTs,
mailboxes, etc. Thus, many programs (not all) on VMS are
written in a callback/closure style.
I imagine that could become complicated very quickly and presumably relies >>on the OS providing the signalling mechanisms for everything you might
want to do - eg waiting for a socket connection (or whatever the decnet >>equivalent was).
It's a fairly common way to structure software even today. As I
On Mon, 6 Jan 2025 14:08:44 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlg4mb$1hi6d$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation >>>>>>on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible
for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
a bunch of them at DEC. They would instinctively turn away from Unix ways >>>>>>of doing things, like forking multiple processes. So the systems they >>>>>>created did not encourage such techniques.
Presumably VMS relied heavily on multithreading then like Windows or was a >>>>>process expected to everything itself sequentially?
Many system services on VMS are asynchronous, and the system >>>>architecture provides a mechanisms to signal completion; ASTs, >>>>mailboxes, etc. Thus, many programs (not all) on VMS are
written in a callback/closure style.
I imagine that could become complicated very quickly and presumably relies >>>on the OS providing the signalling mechanisms for everything you might >>>want to do - eg waiting for a socket connection (or whatever the decnet >>>equivalent was).
It's a fairly common way to structure software even today. As I
In Windows yes, which frankly is probably not a coincidence. Not so much
in unix unless you're writing a GUI program.
Muttley@DastardlyHQ.org writes:
In Windows yes, which frankly is probably not a coincidence. Not so much
in unix unless you're writing a GUI program.
ASTs and unix signals have similar semantics. It's certainly possible to >use, for example, SIGIO in a similar manner to the VMS AST, where the
AST signals I/O completion and the AST handler initiates a subsequent >operation.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlg4mb$1hi6d$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?
Almost certainly not. Because process creation is an expensive operation >>>>>>on Windows.
Windows NT was masterminded by Dave Cutler, who was previously responsible
for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
a bunch of them at DEC. They would instinctively turn away from Unix ways >>>>>>of doing things, like forking multiple processes. So the systems they >>>>>>created did not encourage such techniques.
Presumably VMS relied heavily on multithreading then like Windows or was a >>>>>process expected to everything itself sequentially?
Many system services on VMS are asynchronous, and the system >>>>architecture provides a mechanisms to signal completion; ASTs, >>>>mailboxes, etc. Thus, many programs (not all) on VMS are
written in a callback/closure style.
I imagine that could become complicated very quickly and presumably relies >>>on the OS providing the signalling mechanisms for everything you might >>>want to do - eg waiting for a socket connection (or whatever the decnet >>>equivalent was).
It's a fairly common way to structure software even today. As I
In Windows yes, which frankly is probably not a coincidence. Not so much
in unix unless you're writing a GUI program.
In article <vlgots$1le5s$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>In Windows yes, which frankly is probably not a coincidence. Not so much
in unix unless you're writing a GUI program.
Very much in Unix, actually. The kernel is highly asynchronous
(it must be, to match the hardware), and has been since the
early 1970s. Many user programs similarly.
Historically, many systems have provided direct support for
asynchronous programming on Unix. Going back to the early
commerical Unix days, masscomp's real time Unix had ASTs, not
signals, to support asynch IO directly from userspace. More
recently, POSIX.1b and POSIX AIO are widely supported. Polling
interfaces like kqueue and epoll, etc, exist largely to support
On Mon, 06 Jan 2025 15:05:33 GMT
scott@slp53.sl.home (Scott Lurndal) wibbled:
Muttley@DastardlyHQ.org writes:
In Windows yes, which frankly is probably not a coincidence. Not so much >>>in unix unless you're writing a GUI program.
ASTs and unix signals have similar semantics. It's certainly possible to >>use, for example, SIGIO in a similar manner to the VMS AST, where the
AST signals I/O completion and the AST handler initiates a subsequent >>operation.
Unix signals should only be used to set flags that are then read later.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlgots$1le5s$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>In Windows yes, which frankly is probably not a coincidence. Not so much >>>in unix unless you're writing a GUI program.
Very much in Unix, actually. The kernel is highly asynchronous
(it must be, to match the hardware), and has been since the
early 1970s. Many user programs similarly.
Historically, many systems have provided direct support for
asynchronous programming on Unix. Going back to the early
commerical Unix days, masscomp's real time Unix had ASTs, not
signals, to support asynch IO directly from userspace. More
recently, POSIX.1b and POSIX AIO are widely supported. Polling
interfaces like kqueue and epoll, etc, exist largely to support
Multiplexing is not asychronous, its simply offloading status checking to
the kernel.
The program using is still very much sequential , at least at
that point.
Posix AIO is not asynch in the strict sense , its more "ok kernel, go do this >and I'll check how you're doing later". Proper asynch where the program >execution path gets bounced around between various callbacks is something >else entirely.
Muttley@DastardlyHQ.org writes:...
Unix signals should only be used to set flags that are then read later.
You're opinion is not widely shared. Note that the POSIX specification carefully notes which interfaces are not signal-safe.
Unix signals should only be used to set flags that are then read later. Doing anything complicated in a signal handler is asking for trouble as you have
no idea where the program was when the signal occured and there can be all sorts of re-entrant issues or even deadlocks if using mutexes.
On 1/6/25 11:46, Scott Lurndal wrote:
Muttley@DastardlyHQ.org writes:...
Unix signals should only be used to set flags that are then read later.
You're opinion is not widely shared. Note that the POSIX specification
carefully notes which interfaces are not signal-safe.
What precisely does "signal-safe" mean? As I understand it, it is
supposed to be safe for a signal to interrupt standard library routines,
but that it's not safe for a signal handler to call most of those
functions. There's just a few exceptions, described below.
The C standard says the following about signal handlers:
"The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static or thread storage duration. >239)" (7.1.4p4)
Footnote 239 says "Thus, a signal handler cannot, in general, call
standard library functions."
[snip]
"If a signal occurs other than as the result of calling the abort or
raise functions, the behavior is undefined if the signal handler reads
or modifies an atomic object that has an indeterminate representation." >(7.17.2p2)
"If a signal occurs other than as the result of calling the abort or
raise functions, the behavior is undefined if the signal handler calls
the atomic_init generic function." (7.17.2.1p4)
The POSIX standard claims that its version of <signal.h> conforms to the
C standard, and as far as I can see, the POSIX standard doesn't say
anything to define the behavior that is undefined by the C standard.
Could you demonstrate how, within the above restrictions, a signal
handler that doesn't cause the program to exit in one fashion or another >could do anything useful other than "set flags that are read later"?
I'm not saying it cannot be done. I claim no expertise in this kind of >programming - I never needed to write signal handlers.
However, the last
time I considered the matter carefully (which was two or three versions
of the C standard ago) I couldn't figure out how to do much more than
that. At that time I did not consider how POSIX affects the issue, and I >don't know enough about POSIX signals to evaluate that issue.
On 1/6/25 11:46, Scott Lurndal wrote:
Muttley@DastardlyHQ.org writes:...
Unix signals should only be used to set flags that are then read later.
You're opinion is not widely shared. Note that the POSIX specification
carefully notes which interfaces are not signal-safe.
Could you demonstrate how, within the above restrictions, a signal
handler that doesn't cause the program to exit in one fashion or another >could do anything useful other than "set flags that are read later"?
I'm not saying it cannot be done. I claim no expertise in this kind of >programming - I never needed to write signal handlers. However, the last
time I considered the matter carefully (which was two or three versions
of the C standard ago) I couldn't figure out how to do much more than
that. At that time I did not consider how POSIX affects the issue, and I >don't know enough about POSIX signals to evaluate that issue.
On 1/6/25 11:46, Scott Lurndal wrote:
Muttley@DastardlyHQ.org writes:...
Unix signals should only be used to set flags that are then read later.
You're opinion is not widely shared. Note that the POSIX specification
carefully notes which interfaces are not signal-safe.
What precisely does "signal-safe" mean?
Not so much in unix unless you're writing a GUI program.
I am no expert, but I guess if you need to do async programming on
UNIX/Linux userspace, your best is to use POSIX Threads.
On Mon, 6 Jan 2025 17:53:20 -0000 (UTC), Kalevi Kolttonen wrote:
I am no expert, but I guess if you need to do async programming on
UNIX/Linux userspace, your best is to use POSIX Threads.
Threads are something you normally want to avoid, unless CPU usage is the >bottleneck in your application.
On Mon, 6 Jan 2025 17:53:20 -0000 (UTC), Kalevi Kolttonen wrote:
I am no expert, but I guess if you need to do async programming on
UNIX/Linux userspace, your best is to use POSIX Threads.
Threads are something you normally want to avoid, unless CPU usage is the >>bottleneck in your application.
Complete and utter nonsense.
Posix AIO is not asynch in the strict sense , its more "ok kernel, go do
this and I'll check how you're doing later".
I am no expert, but I guess if you need to do async programming
on UNIX/Linux userspace, your best is to use POSIX Threads.
The communication mechanisms between POSIX
threads and Unix I/O are completely alien to each-other: it is not
possible to poll() on a thread condition, nor is it it possible to set
up a condition to be woken by data on a file descriptor.