C / C++ / MFC

Re: queues to find minimum time to serve all.

22-Oct-20 0:04

The very minimum for you to do is to describe the problem, more than "this problem". Then you should go on to show what you have done, and where you are stuck.

You can't expect people to promise to solve your problems when you haven't even told what the problem is!

Richard MacCutchan22-Oct-20 0:16

Re: queues to find minimum time to serve all.

22-Oct-20 0:16

Use Google to learn about queue theory: queue minimum time - Google Search[^]

David Crow22-Oct-20 3:58

David Crow

22-Oct-20 3:58

fecomevi wrote:
Can you help please, it is a problem just to learn about how to approach queue problems.

A queue is a FIFO data structure. What exactly are you doing with it? Are you using std::queue, or a home-grown version? What code do you have in place so far?

Abort Retry and Ignore and SEH

ForNow19-Oct-20 15:57

19-Oct-20 15:57

Is Abort Retry Ignore something to be implemented by Structured Exception Handlers google the two didn't seem like there is a connection

thanks

Victor Nijegorodov19-Oct-20 20:49

Victor Nijegorodov

19-Oct-20 20:49

Well, I understand that "Brevity is the soul of wit.", but could you explain more specific what your problem is and the relation between "Abort Retry Ignore" and "Structured Exception Handlers" in this context?

Richard MacCutchan19-Oct-20 21:21

19-Oct-20 21:21

There is no such thing as "Abort Retry Ignore" per se. They are merely potential replies to dialog/message boxes. What you do with each individual reply is entirely your choice.

trønderen19-Oct-20 22:28

19-Oct-20 22:28

There is no such thing as "Abort Retry Ignore" per se.

The closest I can think of is one old machine I knew: A fault handler would receive the address of the faulting instruction and a pointer to the register block, with the program pointer set to the following instruction. So, default handler return was "Ignore". Copying the faulting address to the program counter before handler return would be "Retry" at instruction level. Copying the return address from the stack frame pointed to by SP would be "Abort" at the function call level. (The handler could traverse the stack to find an outer return address.)

This is "Abort Retry Ignore" at instuction level, not directly appliccable to SEH. Actually, I am not certain that compiler writers made much use of the mechanisms at all. This machine offered several other features intended to make life easier for the software, but the software guys said "Nah. We'll do it our own way".

ForNow20-Oct-20 1:41

20-Oct-20 1:41

So the pcontext structure (which is in the pxeception pointer parameter structure) which has the registers is what I can manipulate the os windows will use those to continue processing
on abend the eip points to he instruction after the abend backing up the eip would allow me to do a retry

thanks

trønderen20-Oct-20 5:20

20-Oct-20 5:20

This machine I mentioned was not a Windows machine, and not an Intel architecture. At instruction / register level, you cannot expect any one-to-one mapping of concepts.

Also, you cannot map software concepts, like an exception handler, directly onto the interrupt system of every different CPU architecture. Often, a compiler will add a lot of its own to the basic hardware mechanisms. E.g. most exception mechanisms identify the proper handler by the static nesting, but that is within one function. Languages with nested function definitions, "Pascal style", may define handler identification and/or propagation by the overall nesting structure, requiring the static link in the stack frame to be followed. Unless you know every tiny detail of how the compiler generates code, and the runtime handler library (which may be written in assembly code and diverge from the compiler's code generation style), manipulating return addresses and other register contents is likely to mess up your system completely. (And don't forget that hardware fault handlers may be running in privileged mode, allowing you to really mess up your system!)

So, if you work at software SEH level, stick to that level, and don't mess with registers and return addresses.

(My comment was meant as an aside to the "Abort, Retry or Ignore?" not existing per se - just to illustrate that you can get close. I didn't intend it as a viable solution to your problem!)

ForNow20-Oct-20 1:42

20-Oct-20 1:42

in the SEH I can set the EIP from the pcontext structure to the abended instruction to do a retry right ?

Richard MacCutchan20-Oct-20 2:50

20-Oct-20 2:50

I have no idea what that means. Please provide some proper context to your questions.

ForNow20-Oct-20 3:14

20-Oct-20 3:14

What I’m saying is the context structure which windows passes me in the SEH with the registers and eip is What windows will use to resume execution I can set the eip to the next instruction to be executed right ?

Greg Utas20-Oct-20 3:32

Greg Utas

20-Oct-20 3:32

If you retry, what makes you think the outcome will be any different? If you do it automatically, there's a good chance you'll end up in a retry loop. If you continue with the next instruction, well, it's not called undefined behavior for nothing. It's best to generate a stack trace to help you debug and fix the problem. I've written an article[^] about this.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

ForNow20-Oct-20 5:10

20-Oct-20 5:10

Maybe I can better explain the problem. A lot of times I have code that works perfect in debug and then in release blows up
what I would like my SEH handler to do is debug break at the abend. not quite sure how to go about this. In my SEH I unwind the stack to get to the right place

I guess at that point I can Messagebox the line number and do a debugbrk ?

Greg Utas20-Oct-20 6:11

Greg Utas

20-Oct-20 6:11

I've not done debug breaks out of code, so I can't help you there. If your code works in debug, but not in release, it's probably using uninitialized data. One issue that you could face is that, in a release build, the compiler may have optimized the code to the point where it's difficult to follow.

What I do in the SEH is map it to a POSIX signal (e.g. SIGABRT), raise that, catch it in the signal handler, and throw a C++ exception that my base Thread class will catch. The constructor for the exception captures the function call chain before the stack is unwound, and the chain then gets displayed in a log.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

trønderen20-Oct-20 5:40

20-Oct-20 5:40

Greg Utas wrote:
If you retry, what makes you think the outcome will be any different?

Just retrying blindly usually makes little sense. However, the handler may have taken steps to remedy the situation.

Say if you have this (instruction level) memory allocation mechanism, failing because no free block of the requested size was available. The handler could do a heap compaction, and if that fails to create a big enough free block, allocate more memory to the heap from a lower level mechanism, and then request the application to retry the allocation instruction.

Any handler trying to remedy a fault situation (whether at instruction level or higher software level) should keep track of the retries. If the same fault occurs repeatedly, retries should be reconsidered. I have seen several examples where such strategies were followed, e.g. in telephone switches where software modules where updated while the system was running: If an updated module caused a fault for the third time, the previous (and presumably stable) version was automatically reinstated.

(In some areas, computer network guys could learn a few things from the telecom guys! It is a pity that IP networks are pushing out traditional telecom networks before we got ourselves to pick up that knowledge before it is forgotten!)

EACCES file from Ftpfolder

Greg Utas20-Oct-20 6:19

Greg Utas

20-Oct-20 6:19

That kind of retry is possible, but it's unusual. My background was also telecom switches, and we used pools of fixed-size blocks, each dedicated to a specific subsystem, instead of a heap. It was similar to what I describe in this article[^], in which an orphaned block gets recovered by a background garbage collector if it remains unclaimed by the application that allocated it.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

ForNow16-Oct-20 3:47

16-Oct-20 3:47

Hi
I get eacces Return code when I try to open a file in my ftp folder I try to open it read only

Wondering a few things I created a while ago not sure it’s password protected ( don’t think so )
Or maybe I have to use FTP api to copy it or read it
Wondering if any one has had any experience with this
Thanks

Richard MacCutchan16-Oct-20 4:05

16-Oct-20 4:05

I think we need some more details. Can you access the folder to get a directory listing? Is this a local or remote folder? Do you have administrator access to the folder/file? Is this at a command prompts or in some application?

ForNow16-Oct-20 4:19

16-Oct-20 4:19

From a Windows MFC program
I have notify callback whenever the directory changes. I download via EZAFTPKA program Ftp api on z/os a binary file ( sysadata of a program this is like pdb in VS) after the notify file added I try to _sopen for read only
Thanks

Richard MacCutchan16-Oct-20 5:08

16-Oct-20 5:08

This may be a simple matter of Windows not trusting the source of the file. I know that sometimes when downloading files Windows will semi-quarantine them and you need to enable access manually. Take a look at the file itself and check the properties.

ForNow16-Oct-20 5:44

16-Oct-20 5:44

I know this code worked once since that time I installed Norton wonder if that’s getting in the Way

Guess you don’t think it’s an FTP issue ok thanks

Richard MacCutchan16-Oct-20 5:46