| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 27 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 55:04:16 |
| Calls: | 481 |
| Calls today: | 13 |
| Files: | 1,071 |
| Messages: | 95,803 |
| Posted today: | 2 |
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.
Muttley@DastardlyHQ.org writes:
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.
You're opinion is not widely shared. Note that the POSIX specification >carefully notes which interfaces are not signal-safe.
Muttley@dastardlyhq.org wrote:
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.
That is what I have learned, too, but I cannot remember the
source. Maybe one of Richard Stevens' UNIX books.
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.
In article <vlgun1$1minf$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Mon, 6 Jan 2025 15:22:51 -0000 (UTC)
Multiplexing is not asychronous, its simply offloading status checking to >>the kernel.
Of course. It's a means to allow a program to respond to
asynchronous events.
The program using is still very much sequential , at least at
that point.
But the events are not. That's the point. This allows a
program to initiate a non-blocking IO operation (like, say,
establishing a TCP connection using the sockets API), go do
something else, and check it's status later.
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.
The POSIX AIO interface allows the kernel to generate a signal
to inform the program that an IO operation has completed, e.g.,
by setting up the `aio_sigevent` and `SIGEV_SIGNAL`. It doesn't
get much more asynchronous than that.
Linux offers signalfd, so you can indeed use poll(2) in a thread to be
woken up by any file descriptor, including a signal one (and that includes POSIX real-time signals).
Kalevi Kolttonen, dans le message <vlh5ag$1nruu$1@dont-email.me>, a
Θcritá:
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.
Very common misconception.
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. As a result, anybody who tries to >use threads to solve problems of I/O concurrency ends up having to implement >a poll() or equivalent loop in each thread, defeating the purpose.
POSIX threads are good to improve on computation concurrency, but they do
not make I/O concurrency simpler, quite the opposite.
The same might not be true for other kinds of threads.
In article <vlip2c$24ccb$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Mon, 06 Jan 2025 16:46:56 GMT
ITYF it is VERY widely shared and having a signal safe API function is only >>step 2 - plenty of the functions in the program itself or 3rd party library >>functions are probably not re-entrant safe and even if they are, having >>code stomp over itself - eg if in the middle of writing a log message then a >>signal is generated which tried to write a log message itself - is a very >>poor way to write code.
So don't write code that way. It does not follow that the only
thing you can do in a signal handler is an some atomic flag
somewhere.
scott@slp53.sl.home (Scott Lurndal) wibbled:
Muttley@DastardlyHQ.org writes:
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.
You're opinion is not widely shared. Note that the POSIX specification >>carefully notes which interfaces are not signal-safe.
ITYF it is VERY widely shared and having a signal safe API function is only >step 2 - plenty of the functions in the program itself or 3rd party library >functions are probably not re-entrant safe and even if they are, having
code stomp over itself - eg if in the middle of writing a log message then a >signal is generated which tried to write a log message itself - is a very >poor way to write code.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlgun1$1minf$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Mon, 6 Jan 2025 15:22:51 -0000 (UTC)
Multiplexing is not asychronous, its simply offloading status checking to >>>the kernel.
Of course. It's a means to allow a program to respond to
asynchronous events.
Thats not the same as the program itself being asynch.
The program using is still very much sequential , at least at
that point.
But the events are not. That's the point. This allows a
program to initiate a non-blocking IO operation (like, say,
establishing a TCP connection using the sockets API), go do
something else, and check it's status later.
Thats not proper asych, its still sequential. Proper asynch is when the >program execution path is directly modified by external events. Otherwise
you could claim simply using the standard file I/O system is asynchronous >programming as there's no guarantee that any data has been written to the disk >before write(), fprintf() etc return.
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.
The POSIX AIO interface allows the kernel to generate a signal
to inform the program that an IO operation has completed, e.g.,
by setting up the `aio_sigevent` and `SIGEV_SIGNAL`. It doesn't
get much more asynchronous than that.
Sure, but as I've said before, signals should only set flags to be processed >later.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlip2c$24ccb$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Mon, 06 Jan 2025 16:46:56 GMT
ITYF it is VERY widely shared and having a signal safe API function is only >>>step 2 - plenty of the functions in the program itself or 3rd party library >>>functions are probably not re-entrant safe and even if they are, having >>>code stomp over itself - eg if in the middle of writing a log message then a >>>signal is generated which tried to write a log message itself - is a very >>>poor way to write code.
So don't write code that way. It does not follow that the only
thing you can do in a signal handler is an some atomic flag
somewhere.
Just because you can doesn't mean you should. C lets you do a lot of things >that are a Bad Idea.
Lawrence D'Oliveiro , dans le message <vli2lj$1t3lt$8@dont-email.me>, a
Θcritá:
Linux offers signalfd, so you can indeed use poll(2) in a thread to be
woken up by any file descriptor, including a signal one (and that includes >> POSIX real-time signals).
Proving my point that you need to use poll() even when doing threads.
In article <vljcbk$27v6l$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Tue, 7 Jan 2025 13:18:54 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlip2c$24ccb$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>>On Mon, 06 Jan 2025 16:46:56 GMT
ITYF it is VERY widely shared and having a signal safe API function is only >>>>step 2 - plenty of the functions in the program itself or 3rd party library >>>>functions are probably not re-entrant safe and even if they are, having >>>>code stomp over itself - eg if in the middle of writing a log message then >a
signal is generated which tried to write a log message itself - is a very >>>>poor way to write code.
So don't write code that way. It does not follow that the only
thing you can do in a signal handler is an some atomic flag
somewhere.
Just because you can doesn't mean you should. C lets you do a lot of things >>that are a Bad Idea.
I have to ask at this point: have you ever written a concurrent
program under Unix? One that used signals? For that matter,
have you ever written a program that used `fork()` and caught a
`SIGCHLD`?
In article <vlioum$24bqm$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Mon, 6 Jan 2025 16:39:49 -0000 (UTC)
Thats not the same as the program itself being asynch.
Isn't it? The point is that the program kicks off multiple
Thats not proper asych, its still sequential. Proper asynch is when the >>program execution path is directly modified by external events. Otherwise >>you could claim simply using the standard file I/O system is asynchronous >>programming as there's no guarantee that any data has been written to the >disk
before write(), fprintf() etc return.
This is conflating multiple things. Most IO operations dealing
with the actual hardware _are_ asynchronous (this is what
McIlroy meant in the quote I posted earlier). The system call
interface gives the program the illusion of those happening
sequentially, but that's not how the devices really work.
Sure, but as I've said before, signals should only set flags to be processed >>later.
You said that, but that flies in the face of 50 years of
evidence to the contrary and the letter of the standard. This
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vljcbk$27v6l$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Tue, 7 Jan 2025 13:18:54 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlip2c$24ccb$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
On Mon, 06 Jan 2025 16:46:56 GMT
ITYF it is VERY widely shared and having a signal safe API function is only
step 2 - plenty of the functions in the program itself or 3rd party library
functions are probably not re-entrant safe and even if they are, having >>>>>code stomp over itself - eg if in the middle of writing a log message then >>a
signal is generated which tried to write a log message itself - is a very >>>>>poor way to write code.
So don't write code that way. It does not follow that the only
thing you can do in a signal handler is an some atomic flag
somewhere.
Just because you can doesn't mean you should. C lets you do a lot of things >>>that are a Bad Idea.
I have to ask at this point: have you ever written a concurrent
program under Unix? One that used signals? For that matter,
have you ever written a program that used `fork()` and caught a
`SIGCHLD`?
Is that supposed to be a serious question?
The only thing that should ever be done in a child exit handler is a wait*() >or set a flag.
In article <vlioum$24bqm$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
Thats not proper asych, its still sequential. Proper asynch is when the >>program execution path is directly modified by external events. Otherwise >>you could claim simply using the standard file I/O system is asynchronous >>programming as there's no guarantee that any data has been written to the disk
before write(), fprintf() etc return.
This is conflating multiple things. Most IO operations dealing
with the actual hardware _are_ asynchronous (this is what
McIlroy meant in the quote I posted earlier). The system call
interface gives the program the illusion of those happening
sequentially, but that's not how the devices really work.
It turns out the simple model of early research Unix was
insufficient for handling all sorts of important use cases,
hence why interfaces like `select` and `poll` were added.
In article <vljgbg$28o6f$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Tue, 7 Jan 2025 14:14:38 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vljcbk$27v6l$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>>On Tue, 7 Jan 2025 13:18:54 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlip2c$24ccb$1@dont-email.me>, <Muttley@DastardlyHQ.org> >wrote:
On Mon, 06 Jan 2025 16:46:56 GMT
ITYF it is VERY widely shared and having a signal safe API function is >only
step 2 - plenty of the functions in the program itself or 3rd party >library
functions are probably not re-entrant safe and even if they are, having >>>>>>code stomp over itself - eg if in the middle of writing a log message then
a
signal is generated which tried to write a log message itself - is a very >>>>>>poor way to write code.
So don't write code that way. It does not follow that the only
thing you can do in a signal handler is an some atomic flag >>>>>somewhere.
Just because you can doesn't mean you should. C lets you do a lot of things >>>>that are a Bad Idea.
I have to ask at this point: have you ever written a concurrent
program under Unix? One that used signals? For that matter,
have you ever written a program that used `fork()` and caught a >>>`SIGCHLD`?
Is that supposed to be a serious question?
Yes.
The only thing that should ever be done in a child exit handler is a wait*() >>or set a flag.
I think perhaps you should try to write some complex programs in
the Unix environment before making such categorial statement.
This, however, does not follow. I don't see why "poll" is
strictly required for IO concurrency.
Dan Cross, dans le message <vljbvv$gl9$1@reader2.panix.com>, a Θcritá:
This, however, does not follow. I don't see why "poll" is
strictly required for IO concurrency.
Well, try to do implement anything non-trivial involving I/O concurrency, >including timeouts, clients causing other clients to abort, etc., with
the common denominator of POSIX threads and come back telling us how you >managed that.
I tried, and stopped trying using threads for I/O concurrency.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vlioum$24bqm$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Mon, 6 Jan 2025 16:39:49 -0000 (UTC)
Thats not the same as the program itself being asynch.
Isn't it? The point is that the program kicks off multiple
Not, it isn't. Using operating system facilities is standard programming, its >not asych programming whereby the program execution will be automatically
be diverted when an operation completes.
Thats not proper asych, its still sequential. Proper asynch is when the >>>program execution path is directly modified by external events. Otherwise >>>you could claim simply using the standard file I/O system is asynchronous >>>programming as there's no guarantee that any data has been written to the >>disk
before write(), fprintf() etc return.
This is conflating multiple things. Most IO operations dealing
with the actual hardware _are_ asynchronous (this is what
McIlroy meant in the quote I posted earlier). The system call
interface gives the program the illusion of those happening
sequentially, but that's not how the devices really work.
And? By your definition its still asynchronous programming.
Sure, but as I've said before, signals should only set flags to be processed >>>later.
You said that, but that flies in the face of 50 years of
evidence to the contrary and the letter of the standard. This
Please don't just make stuff up.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vljgbg$28o6f$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>>[snip]
I have to ask at this point: have you ever written a concurrent
program under Unix? One that used signals? For that matter,
have you ever written a program that used `fork()` and caught a >>>>`SIGCHLD`?
Is that supposed to be a serious question?
Yes.
The only thing that should ever be done in a child exit handler is a wait*() >>>or set a flag.
I think perhaps you should try to write some complex programs in
the Unix environment before making such categorial statement.
Don't be patronising.
I've probably written more unix software in 30 years
than you've had hot dinners including a fully featured telnetd and numerous >other servers for work and play. And in the places I've worked which included >finance/banking, aerospace and government,
the advice was almost always NOT to
use signals in the first place unless there was no choice - eg SIGCHLD - but if
you did then do very little in the handler and nothing that could cause any >re-entrancy issues.
I suspect its you who needs a bit more practice at writing large multi process >and multi threaded applications.
there is no reason you cannot, say, have a signal handler that
broadcasts on a condition variable after an asynchronous IO operation completes, thus waking up a thread.
Dan Cross, dans le message <vljbvv$gl9$1@reader2.panix.com>, a Θcritá:
This, however, does not follow. I don't see why "poll" is
strictly required for IO concurrency.
Well, try to do implement anything non-trivial involving I/O concurrency, >including timeouts, clients causing other clients to abort, etc., with
the common denominator of POSIX threads and come back telling us how you >managed that.
I tried, and stopped trying using threads for I/O concurrency.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
there is no reason you cannot, say, have a signal handler that
broadcasts on a condition variable after an asynchronous IO operation
completes, thus waking up a thread.
The pthread_cond_* calls are not async-signal safe and hence, this is
either undefined behaviour (newly introduced with POSIX.1-2024) or
undefined behaviour if the signal handler interrupted something that
isn't async-signal safe (prior to POSIX.1-2024 and still retained in the >current text).
However, POSIX semaphores can safely be used for that.
In article <vljg72$28nj0$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Tue, 7 Jan 2025 14:13:29 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
This is conflating multiple things. Most IO operations dealing
with the actual hardware _are_ asynchronous (this is what
McIlroy meant in the quote I posted earlier). The system call
interface gives the program the illusion of those happening
sequentially, but that's not how the devices really work.
And? By your definition its still asynchronous programming.
In the kernel, it sure is. Unix programmers have been writing
asynchronous programs (using e.g. `fork`) since 1970.
Please don't just make stuff up.
Hmm. I wonder what shell you use, if you use Unix at all.
Here for example is the signal handler for SIGINT in bash: >https://git.savannah.gnu.org/cgit/bash.git/tree/sig.c?h=devel#n691
Here's the SIGWINCH handler for good 'ol `script` from
OpenBSD: >https://github.com/openbsd/src/blob/6d253f95424ee0054c798f493d12377911cd3668/us
r.bin/script/script.c#L224
Those are just a few examples. If one cares to look, one will
find many more in non-trivial programs used in production daily.
In article <vljiml$296n5$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Tue, 7 Jan 2025 15:35:44 -0000 (UTC)
I think perhaps you should try to write some complex programs in
the Unix environment before making such categorial statement.
Don't be patronising.
Wow, that's rich coming from you, my guy.
I've probably written more unix software in 30 years
than you've had hot dinners including a fully featured telnetd and numerous >>other servers for work and play. And in the places I've worked which included >>finance/banking, aerospace and government,
"For play" implies things that could be, or are, open source.
So post a link to code, then.
Bluntly, I don't believe that any of this is true. Your posts
here show a distinct lack of relevant experience and knowledge.
*shrug* Feel free to look up some things that I've written, if
you like. Perhaps you'll learn something.
"For play" implies things that could be, or are, open source.
So post a link to code, then.
Bluntly, I don't believe that any of this is true. Your posts
here show a distinct lack of relevant experience and knowledge.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vljiml$296n5$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Tue, 7 Jan 2025 15:35:44 -0000 (UTC)
I think perhaps you should try to write some complex programs in
the Unix environment before making such categorial statement.
Don't be patronising.
Wow, that's rich coming from you, my guy.
"My guy?" LOL, how old are you, 12? :)
I've probably written more unix software in 30 years
than you've had hot dinners including a fully featured telnetd and numerous >>>other servers for work and play. And in the places I've worked which included
finance/banking, aerospace and government,
"For play" implies things that could be, or are, open source.
So post a link to code, then.
Nope, I like my relative anonymity here and I don't need to prove anything to >some twat with a chip on his shoulder getting worked up over technical trivia.
Bluntly, I don't believe that any of this is true. Your posts
Believe what you like, I couldn't give a rats arse.
here show a distinct lack of relevant experience and knowledge.
Whatever you say genius.
*shrug* Feel free to look up some things that I've written, if
you like. Perhaps you'll learn something.
Is this yours?
https://github.com/dancrossnyc
Am I supposed to be impressed?
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <vlioum$24bqm$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
Thats not proper asych, its still sequential. Proper asynch is when the >>>program execution path is directly modified by external events. Otherwise >>>you could claim simply using the standard file I/O system is asynchronous >>>programming as there's no guarantee that any data has been written to the disk
before write(), fprintf() etc return.
This is conflating multiple things. Most IO operations dealing
with the actual hardware _are_ asynchronous (this is what
McIlroy meant in the quote I posted earlier). The system call
interface gives the program the illusion of those happening
sequentially, but that's not how the devices really work.
Indeed, and it was subsequently recognized that more than
the 'sync'[*] system call was required for applications to
ensure data was successfully written to the underlying
device.
Applications in those days (e.g. fsck) would access the
raw character device using the unbuffered read() and
write() system calls rather than using stdio. A key
characteristic of raw devices were that the hardware DMA would
use the application buffer directly rather than copying
the data to the kernel buffer pool first.
[*] I recall using 'sync;sync;sync' from the Sixth Edition
command line more than once, before rebooting.
Subsequently APIs like fdatasync(2) and open flags
such as O_DIRECT and O_DSYNC were added.
It turns out the simple model of early research Unix was
insufficient for handling all sorts of important use cases,
hence why interfaces like `select` and `poll` were added.
Although to be fair, select(2) originated with BSD and is
a bit less flexible than poll(2).
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vljg72$28nj0$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Tue, 7 Jan 2025 14:13:29 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
This is conflating multiple things. Most IO operations dealing
with the actual hardware _are_ asynchronous (this is what
McIlroy meant in the quote I posted earlier). The system call >>>>interface gives the program the illusion of those happening >>>>sequentially, but that's not how the devices really work.
And? By your definition its still asynchronous programming.
In the kernel, it sure is. Unix programmers have been writing
asynchronous programs (using e.g. `fork`) since 1970.
Thats not what we're discussion here and you know it.
Please don't just make stuff up.
Hmm. I wonder what shell you use, if you use Unix at all.
Stupid comments really are your forte arn't they.
Here for example is the signal handler for SIGINT in bash: >>https://git.savannah.gnu.org/cgit/bash.git/tree/sig.c?h=devel#n691
Basically sets flags.
Here's the SIGWINCH handler for good 'ol `script` from
OpenBSD: >>https://github.com/openbsd/src/blob/6d253f95424ee0054c798f493d12377911cd3668/us
r.bin/script/script.c#L224
Not a clever way to do it because an xterm and other terminal progs can >indirectly cause a whole load of SIGWINCH to be created if someone is resizing >it and only the final one really needs the ioctl call done. Better to set a >flag then manually do a call when appropriate.
Those are just a few examples. If one cares to look, one will
find many more in non-trivial programs used in production daily.
There are always exceptions to every rule. You seem to be so desperate to
win this argument I can only assume your fragile ego has been burst by >someone having the temerity to disagree with you. Tough, suck it up.
In article <vljjmf$g76$2@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
...
"For play" implies things that could be, or are, open source.
So post a link to code, then.
Bluntly, I don't believe that any of this is true. Your posts
here show a distinct lack of relevant experience and knowledge.
Or dementia. Lot of that going around in the world today.
Many Usenet posters fall into this category. They may have been >smart/accomplished once upon a time, but that was years/decades ago, and
now they're just living on memories.
Seriously, I've seen a lot of this over the years, and we should cut this
guy some slack.
In article <vGbfP.54357$XfF8.7280@fx04.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <vlioum$24bqm$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
Applications in those days (e.g. fsck) would access the
raw character device using the unbuffered read() and
write() system calls rather than using stdio. A key
characteristic of raw devices were that the hardware DMA would
use the application buffer directly rather than copying
the data to the kernel buffer pool first.
They still do!
On 07 Jan 2025 15:54:48 GMT Nicolas George <nicolas$george@salle-s.org> wibbled:
I tried, and stopped trying using threads for I/O concurrency.
For some mad reason it seems to be the way to do it in Windows and also
Java IIRC.
Lawrence D'Oliveiro , dans le message <vli2lj$1t3lt$8@dont-email.me>, a
écrit :
Linux offers signalfd, so you can indeed use poll(2) in a thread to be
woken up by any file descriptor, including a signal one (and that
includes POSIX real-time signals).
Proving my point that you need to use poll() even when doing threads.
On 07 Jan 2025 08:59:28 GMT, Nicolas George wrote:
Lawrence D'Oliveiro , dans le message <vli2lj$1t3lt$8@dont-email.me>, a
écrit :
Linux offers signalfd, so you can indeed use poll(2) in a thread to be
woken up by any file descriptor, including a signal one (and that
includes POSIX real-time signals).
Proving my point that you need to use poll() even when doing threads.
But you said “it is not possible to poll() on a thread condition”, when it >fact such usage is commonplace, as I pointed out.
It is perfectly possible to poll() on a thread condition. See pipe(2).
In article <vljmlt$29vt3$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Tue, 7 Jan 2025 16:10:55 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
Nope, I like my relative anonymity here and I don't need to prove anything to >>some twat with a chip on his shoulder getting worked up over technical trivia.
Ok. So we're just supposed to take your word for it, I guess.
Got it.
Believe what you like, I couldn't give a rats arse.
You also have no evidence to back up your claims, it seems.
Am I supposed to be impressed?
*shrug* I think my credentials speak for themselves. I really
don't care whether you're impressed or not.
On Tue, 7 Jan 2025 15:56:46 -0000 (UTC), Muttley wrote:
On 07 Jan 2025 15:54:48 GMT Nicolas George <nicolas$george@salle-s.org>
wibbled:
I tried, and stopped trying using threads for I/O concurrency.
For some mad reason it seems to be the way to do it in Windows and also
Java IIRC.
Remember the era: it was the 1990s, when threads were still a new thing to
PC OSes, and they were considered the best way to do everything involving >nondeterminism, including GUIs.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <vGbfP.54357$XfF8.7280@fx04.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <vlioum$24bqm$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
Applications in those days (e.g. fsck) would access the
raw character device using the unbuffered read() and
write() system calls rather than using stdio. A key
characteristic of raw devices were that the hardware DMA would
use the application buffer directly rather than copying
the data to the kernel buffer pool first.
They still do!
Well, not on linux. Even O_DIRECT still goes through
the file cache, last I checked.
I submitted a 'raw device' patch to the linux mailing
list in the late 90s while at SGI. It wasn't accepted because
O_DIRECT was considered sufficient, even with the spurious
copy. The overhead of pinning the user space pages was
considered onerous.
In article <vljmc6$29tkd$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Tue, 7 Jan 2025 16:02:51 -0000 (UTC)
In the kernel, it sure is. Unix programmers have been writing >>>asynchronous programs (using e.g. `fork`) since 1970.
Thats not what we're discussion here and you know it.
Actually, it is.
https://git.savannah.gnu.org/cgit/bash.git/tree/sig.c?h=devel#n691
Basically sets flags.
Did you actually read and understand any of that code?
Not a clever way to do it because an xterm and other terminal progs can >>indirectly cause a whole load of SIGWINCH to be created if someone is >resizing
it and only the final one really needs the ioctl call done. Better to set a >>flag then manually do a call when appropriate.
Ok. You may even be right! But tell me: where would you check
those flags?
Regardless, here you are, again, moving the goalposts in the
face of evidence that contradicted your earlier position.
There are always exceptions to every rule. You seem to be so desperate to >>win this argument I can only assume your fragile ego has been burst by >>someone having the temerity to disagree with you. Tough, suck it up.
Ah, here we go. The classic attempt at an insult.
Look, you made categorical, definitive statements. Those
statements were factually incorrect. I pointed that out. You
Perhaps I am not the one with the fragile ego that needs to suck
it up when disagreed with.
Scott Lurndal, dans le message <BcmfP.289889$aTp4.50420@fx09.iad>, a
Θcritá:
It is perfectly possible to poll() on a thread condition. See pipe(2).
It is possible to write code to wake a thread blocked in poll(). I have not >tried to deny this. It is not possible to poll() directly on a thread >condition. You have not disproved that.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vljmlt$29vt3$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Tue, 7 Jan 2025 16:10:55 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
Nope, I like my relative anonymity here and I don't need to prove anything to
some twat with a chip on his shoulder getting worked up over technical trivia.
Ok. So we're just supposed to take your word for it, I guess.
Got it.
In one.
Believe what you like, I couldn't give a rats arse.
You also have no evidence to back up your claims, it seems.
Plenty of evidence out there.
Am I supposed to be impressed?
*shrug* I think my credentials speak for themselves. I really
don't care whether you're impressed or not.
What credentials? You work for some neverheardofit software house and have >mostly done a load of forks of other peoples code. Standard dev stuff, nothing >special.
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
In article <vljmc6$29tkd$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>On Tue, 7 Jan 2025 16:02:51 -0000 (UTC)
In the kernel, it sure is. Unix programmers have been writing >>>>asynchronous programs (using e.g. `fork`) since 1970.
Thats not what we're discussion here and you know it.
Actually, it is.
Ah ok, goalposts moved. Why not some straw men while you're at it?
https://git.savannah.gnu.org/cgit/bash.git/tree/sig.c?h=devel#n691
Basically sets flags.
Did you actually read and understand any of that code?
Did you?
Not a clever way to do it because an xterm and other terminal progs can >>>indirectly cause a whole load of SIGWINCH to be created if someone is >>resizing
it and only the final one really needs the ioctl call done. Better to set a >>>flag then manually do a call when appropriate.
Ok. You may even be right! But tell me: where would you check
those flags?
Presuably a genius like you would know most terminal programs have a seperate >thread or a multiplex timeout in order to flash the cursor. You work out
the rest.
Regardless, here you are, again, moving the goalposts in the
face of evidence that contradicted your earlier position.
Irony, love it.
There are always exceptions to every rule. You seem to be so desperate to >>>win this argument I can only assume your fragile ego has been burst by >>>someone having the temerity to disagree with you. Tough, suck it up.
Ah, here we go. The classic attempt at an insult.
If the shoe fits.
Look, you made categorical, definitive statements. Those
statements were factually incorrect. I pointed that out. You
No, I stated the majority approach to using signals. You disagree which is >fine, but don't pretent your view is THE view, it isn't.
Perhaps I am not the one with the fragile ego that needs to suck
it up when disagreed with.
Ego size on usenet is almost always correlated with the verbiage of a reply.
In article <vllcml$2mqb8$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Tue, 7 Jan 2025 17:23:01 -0000 (UTC)
You also have no evidence to back up your claims, it seems.
Plenty of evidence out there.
Plenty of contradictory evidence, you mean.
What credentials? You work for some neverheardofit software house and have >>mostly done a load of forks of other peoples code. Standard dev stuff, nothing
special.
Yeah, ok, sure.
I think it's important to define what you mean when you write,
"thread condition." What, exactly, is that? Perhaps you mean
a condition variable?
If so, that's true, but I fail to see
the relevance: people write multithreaded code that does IO in
multiple all the time; there are some techniques that are common
for this (Scott alluded to the so-called "pipe trick", due to
Bernstein) and some that are less common.
In article <vllcgq$2mphu$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>On Tue, 7 Jan 2025 17:19:56 -0000 (UTC)
Presuably a genius like you would know most terminal programs have a seperate >>thread or a multiplex timeout in order to flash the cursor. You work out >>the rest.
Right, handwave away those very real concerns. We're talking
about Unix here, not code running on some microcontroller; code
No, I stated the majority approach to using signals. You disagree which is >>fine, but don't pretent your view is THE view, it isn't.
Bluntly, I don't see any evidence that you are qualified enough
to make any statement regarding the "majority approach" to,
Ego size on usenet is almost always correlated with the verbiage of a reply.
I'm not the one who started with dishing out insults at the
first person who disagreed with me.
Feel free to have the last word, but absent some actually
technical point, I'm done with you.
Dan Cross, dans le message <vllql7$sn6$2@reader2.panix.com>, a écrit :
I think it's important to define what you mean when you write,
"thread condition." What, exactly, is that? Perhaps you mean
a condition variable?
Yes, of course that is what “thread condition” means in the context of a >discussion about POSIX threads.
POSIX threads do not make I/O concurrency easier, they are not made for
that, they are for performance.
Dan Cross, dans le message <vllql7$sn6$2@reader2.panix.com>, a écrit :
I think it's important to define what you mean when you write,
"thread condition." What, exactly, is that? Perhaps you mean
a condition variable?
Yes, of course that is what “thread condition” means in the context of a >discussion about POSIX threads.
If so, that's true, but I fail to see
the relevance: people write multithreaded code that does IO in
multiple all the time; there are some techniques that are common
for this (Scott alluded to the so-called "pipe trick", due to
Bernstein) and some that are less common.
Yes: there are some techniques that are common to implement I/O concurrency >and that work in the context of threads. You are arguing my point for me:
the threads did not make implementing the I/O concurrency simpler; quite the >opposite it they made them harder, as proven by the fact that “techniques” >had to be deployed.
POSIX threads do not make I/O concurrency easier, they are not made for
that, they are for performance.
On Wed, 8 Jan 2025 13:00:01 -0000 (UTC)
I don't need to prove myself to argue with some random troll on a newsgroup. >If you can't handle that thats your problem, not mine.
Muttley@DastardlyHQ.org writes:
On Wed, 8 Jan 2025 13:00:01 -0000 (UTC)
[...]
I don't need to prove myself to argue with some random troll on a
newsgroup. If you can't handle that thats your problem, not mine.
Look in the mirror, nameless troll. [...]
Dan is well known and respected in the Unix world. You, not so much.
I don't need to prove myself to argue with some random troll on a newsgroup. If you can't handle that thats your problem, not mine.
I vaguely remember Oracle complaining about this back in the day meaning
they couldn't guarantee their RDBMS transaction writes on Linux.
On 2025-01-08, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
I don't need to prove myself to argue with some random troll on a newsgroup. >> If you can't handle that thats your problem, not mine.
I have to say, that's pretty tone deaf, as a reply to Dan Cross.
Muttley@DastardlyHQ.org writes:
On Wed, 8 Jan 2025 13:00:01 -0000 (UTC)
I don't need to prove myself to argue with some random troll on a newsgroup. >>If you can't handle that thats your problem, not mine.
Look in the mirror, nameless troll.
Dan is well known and respected in the Unix world. You, not so much.
On Wed, 8 Jan 2025 20:27:54 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wibbled:
On 2025-01-08, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
I don't need to prove myself to argue with some random troll on a newsgroup.
If you can't handle that thats your problem, not mine.
I have to say, that's pretty tone deaf, as a reply to Dan Cross.
Sorry if I don't hero worship like you. If I think someone's talking bollocks then I'll call it out.
The usual "i don't agree with you so you must be a troll" attitude.
[snip]
Dan Cross being a random troll in a newsgroup is an example of bollocks,
and it's being called out.
Even if Dan happened to be caught talking bollocks, it still wouldn't
make him a troll, or random. It's simply not factual or rational.
On 2025-01-15, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
On Wed, 8 Jan 2025 20:27:54 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wibbled:
On 2025-01-08, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
I don't need to prove myself to argue with some random troll on a >newsgroup.
If you can't handle that thats your problem, not mine.
I have to say, that's pretty tone deaf, as a reply to Dan Cross.
Sorry if I don't hero worship like you. If I think someone's talking bollocks
then I'll call it out.
Glad you understand the concept.
Dan Cross being a random troll in a newsgroup is an example of bollocks,
and it's being called out.
Even if Dan happened to be caught talking bollocks, it still wouldn't
make him a troll, or random. It's simply not factual or rational.
On 2025-01-15, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
The usual "i don't agree with you so you must be a troll" attitude.
Rather, it is this accusation that is an extremely common trope.
Rarely is it true.
On Sat, 04 Jan 2025 19:17:15 -0300, Salvador Mirzo wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Windows NT was masterminded by Dave Cutler ...
Is that Dave with a YouTube channel?
No, that’s a different former Microsoftie, but he has had Cutler on his channel for an extended interview.
I found it ironic that there was a PiDP-11, I think it was, placed within arm’s reach behind the guy during the entire interview. You know, the PDP-11 emulator that runs on a Linux-based Raspberry Pi. I wonder if the Unix-hater ever noticed that ...
Its very often true. Calling someone a troll in a newsgroup is a drop-the-mic and walk off because you've lost the argument.
Given that he looks late 20s in his picture he's
certaiunly no greybeard with a long history of contributions.
In article <vmakbg$3eqtn$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>[snip]
Given that he looks late 20s in his picture he's
certaiunly no greybeard with a long history of contributions.
I wish I were still in my late 20s. Perhaps my knees would hurt
less.
And if only my hair (and beard) were more colorful, but sadly, I
went almost totally gray in Afghanistan. Perhaps I'll turn out
In article <vmakbg$3eqtn$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>[snip]
Given that he looks late 20s in his picture he's
certaiunly no greybeard with a long history of contributions.
I wish I were still in my late 20s. Perhaps my knees would hurt
less.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <vmakbg$3eqtn$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote: >>>[snip]
Given that he looks late 20s in his picture he's
certaiunly no greybeard with a long history of contributions.
I wish I were still in my late 20s. Perhaps my knees would hurt
less.
Weren't you at Murray Hill, before the move to Summit?
On Thu, 16 Jan 2025 14:51:40 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
And if only my hair (and beard) were more colorful, but sadly, I2 of my family also served there and they don't act like dicks in online forums.
went almost totally gray in Afghanistan. Perhaps I'll turn out