Re: Continuing Mulberry-Windows issues

--On Saturday, May 06, 2023 2:08 PM -0400 John C Klensin 
<[email protected]> wrote:

> Ack.  And thanks.   Oddly (apparently) although the first
> machine for which I wrote programs still had rotating main
> memory, I had just never run into that particular terminology
> before.  Probably just been away from the relevant communities
> for too long and/or losing with my age.

Exceptions help eliminate all the code to check error codes that make it 
hard to see the "normal" logic of a program. Old code will have an error 
check after every call, and the jump out of the normal flow can be tricky 
if you're trying to avoid goto's. With exceptions, you can put all your 
error handling at the end of a block or function or let the caller deal 
with it. No goto's needed. Think of throw as a structured goto. Debugging 
them can be hard though unless the compiler and debugger conspire to 
include stack information so that the debugger can show you where the throw 
came from.

> Again, couldn't figure out why one machine and not all of the
> others, but, as I think of it, the problem could easily be the
> different in speed of the machines and the ability of the
> current technology (including the i7) to handle more threads
> than the machines of several years ago.  The other complications
> is that, because of Windows file system changes some years back
> (around Win 7 IIR), Mulberry thinks it is writing files to one
> set of locations when in fact the they are ending up somewhere
> else.  The good news is that has worked for years; the bad news
> is that, in my experience, arrangements like that are fragile
> and get worse over time.  Perhaps the "sometimes it writes and
> crash dump and sometimes it cannot" could be part of that
> picture too.

I hadn't thought about the virtual file locations. That was added to deal 
with the long-standing practice of writing to shared areas in what was 
previously a single-user system. *nix went through the same problem decades 
ago so we tend to assume it's a Windows-only issue.

I think you're right that the faster machine with more cores is going to be 
more prone to "race condtions" where whether bad things happen is governed 
by a race between two threads. I cut my teeth in digital logic design where 
I was constantly drawing timing diagrams to solve hardware race conditions, 
so I'm accutely aware of them when writing multi-threaded software. It can 
be tough simulating all those threads in one's head.

> Good to know that is what c0000005 is.  I presume the memory
> locations it gives are of no use whatsoever.  In any event, odd,
> but not inconsistent with the above, especially if the "getting
> rid of" happened in one thread and the access attempt was in
> another.  I have never looked at the code, much less tried to
> understand the internal logic, but the possible picture is
> becoming more clear... maybe along with some surprise that the
> now-ancient code, which I think Cyrus described as old and
> outdated, has been stable and useful for this long.

The C0000005 thing is really error code 5 in subsystem C. The high byte of 
the 32-bit word identifies the subsystem and the rest is the error code. 
That allows different teams at Microsoft to maintain their own sets of 
error codes. Here's a list:

<https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55>

Indeed, the memory errors and race conditions are from operation queues. 
For example, when you send a message, the GUI queues a command with all the 
information to send it onto a list and another thread, a "worker thread", 
dequeues the command later to do the actual SMTP transaction, then the IMAP 
transaction to save it to the Sent folder, and then it queues a command on 
the GUI to report what happened somehow. The command objects often have 
pointers to other objects (like the message body) and it's possible 
something might free an object before another thread is done messing with 
it.

> Wishing I could retire or take an extended vacation from other
> things and just rewrite Mulberry to modern standards, but that
> isn't going to happen.  In the meantime, I should probably keep
> tinkering, keep looking for a migration path that works for me
> and my environment (web mail really doesn't), and maybe think
> about whether I could run Mulberry in some sort of VM setup or
> equivalent that would allow it to run at a more leisurely pace.

I don't want to reinvent the wheel. There are good libraries that do GUI, 
IMAP, and SMTP. So I'd want to use those and just glue them all together. 
The hard part is that some of the libraries are tricky to build. OpenSSL 
has been hard to build because it was originally designed for a *nix build 
system. I'm trying to get it to repeatably build for Windows for use in 
another application. The build system recently got better but it's still 
not for the faint of heart. Mulberry uses it for the encrypted connections 
to the mail servers. So do most IMAP/SMTP libraries. Getting SSL right is 
hard, so it's a bad idea to roll your own.