>>Bob, I don't know the source of your trouble, but as a workaround consider >>running grep -r instead of find | xargs grep. In many cases it's equivalent >>or almost as good, and it probably will avoid all of the forking that's >>causing trouble for you. A. In the case of talking about the memory limitations due by the SharedSection, as Microsoft says that a process uses/allocate spaces in the heap desktop when calling a method of user32.dll &/or indirectly from a method of another dll calling itself user32.dll (like gdi32.dll which call user32.dll), one investigation way could be to remove all calls linking to user32.
I just look with the depends.exe tool which helps to identify dlls dependencies (on linked dlls, not dll loaded dynamically :( ) & I saw that cygwin1.dll, only uses registry methods of advapi32.dll (like RegCloseKey which appears to implement a call to messagebox in user32 at its lower level !!!!) or that bash.exe for example is linked to user32.dll for clipboard management. Removing calls to user32, advapi32.dll, gdi32.dll should help not to be impacted by the sharedsection/heap desktop & finally not impacted by the memory allocated automatically in the desktop heap & also in the process. One way if cygwin really needs some user/gdi/advapi32 calls, should be to write an external cygwin program allowing each cygwin process which needs one of these features to request it to this external unique program (like a windows desktop manager new cygwin process called through pipes or tcpip for executing returning results on calls using directly or indirectly user32 code). In this case, only this external process will uses some heap desktop memory reducing the number of hanging, dead locks & other problems due by the sharedsection on complex user architecture using lot of cygwin programs started in parallel. The problem is that profiling cygwin programs with "Dependency Walkter", cygwin loads lot of API pointers through GetProcAddresss & so loads windows Dll dynamically & so looking for direct linked calls in it on user32 & other libs calling user32 cannot be considered as significant.... I know that lot of you will maybe consider this mail as a big dream (as also it is more complex than saying it through a mail) for rewriting cygwin runtime not to call user32 apis & retrieve informations through another process is pratically impossible & could not be deliver before many years. but I added this contribution also for hopping that it will help other users of cygwin to understand the situation on the shared section limitation also in the case of if bob was talking about this. & That's only in the case, of the information providen by Microsoft in their technotes is relevent ;) Louis -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
