Re: Windows MAGICK_CONFIGURE_PATH options
Bob Friesenhahn <[email protected]> Mon, 9 Mar 2020 11:01:44 -0500 (CDT)
| Newsgroups | gmane.comp.video.graphicsmagick.apis |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3735943886-724081589-1583769704=:19876 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 9 Mar 2020, 10bxjfhf wrote: >> >> I am not aware of a reason other than that Bill Radcliff designed this part >> of the code and while I have made significant changes to the implementation >> over the years, it was not with the intent to change behavior. > IMO, all places where the format is used, ought to follow the same convention > :-) That does sound reasonable. I am not sure where the memory will come from for an arbitrarily large log message stored in one buffer. There are some large log messages which span multiple lines. The memory would need to be allocated in advance or automatically resized. > In my limited testing of the latest changes, there is at least on place where > I am sure I saw some 'lack of resources' comment from the IDE. Unfortunately, > my attention was diverted and I could not follow up at that time. > > Between that point and the very large buffer assignments on the stack, it is > something I want to pay more attention to down the road. The stack size should be somewhat reduced now. This is "just a warning" but of course it is good to reduce the required stack size. It is common that Unix/Linux systems provide 8MB of stack to each thread by default. :-) > For fatal errors, which crash the system, the only way might be the system > log and that perhaps, ought to be the final fall back, no matter what the > user or the log.mgk file specifies. The fatal errors are typically for the case where the OS has no more memory to offer at all given that it is not able to allocate enough memory for a small structure. In this case the program might not execute sanely at all (e.g. might not be able to extend the stack), unless perhaps it happens to immediately free up some memory. Regardless, I do not like the excessive use of fatal errors for failure to allocate structures when the program has already allocated a lot of memory because the problem may be self induced and immediately releasing memory may solve the problem. Regardless, I appreciate your desire for a logging API which can submit to your program's will without depending so much on a configuration file. Bob -- Bob Friesenhahn [email protected], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt --3735943886-724081589-1583769704=:19876 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --3735943886-724081589-1583769704=:19876 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Graphicsmagick-apis mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/graphicsmagick-apis --3735943886-724081589-1583769704=:19876--