Re: [PATCH21.5] regex_malloc_disallowed fix

Here is my solution to the problem: My approach is to fully avoid allocation in the write barrier's signal handler. Basically this means to make the page_fault_table large enough beforehand. Luckily the upper bound of the page_fault_table's size can be determined prior to each write-barrier cycle. The upper bound corresponds to the number of pages that are watched by the write barrier. These are all the pages that contain BLACK objects. This patch includes minimal modifications to determine the number of processed pages, and the call to resize the page_fault_table. Please test. I don't know if this is the best way to deal with it. I read through the comments in regex.c that talk about the connection of REL_ALLOC and regex_malloc_disallowed. I was relieved to read that even Ben had trouble understanding it all. Is somebody around who understands it and can shed light on the regular expressions engine? Would it be better to "be prepared for malloc()", as the comments in regex.c state? Does anybody know how to "prepare"? Can you do this with RE_MATCH_RELOCATE_MOVEABLE_DATA_POINTERS and/or RE_SEARCH_RELOCATE_MOVEABLE_DATA_POINTERS? How expensive is this? Is it more elegant than avoiding malloc in the signal handler and causing memory overhead? Comments welcome!