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--