Re: When is mem.c / malloc called?

[Sebastian Gniazdowski <psprint2@fastmail.com>]

On Fri, Feb 10, 2017, at 10:25 AM, Bart Schaefer wrote:
> } I'm writing a module that needs thread safe memory allocation.
> 
> This sounds pretty dangerous, as the rest of zsh (signal handling in
> particular, update of the environment on e.g. "export", etc.) is not
> going to be thread-safe.
> 

I've ended up copying multiple Zsh functions, calling them
my_{original_name}, creating separate call tree. The goal is to do this
in multi-threaded manner:

# print -rl -- "a,b" "c,d" | zpopulator -D , -vA myhash
# typeset -p myhash
typeset -A myhash=( a b c d )

I basically create a thread after I do:

fdopen( dup( fileno( stdin ) ), "r" );

in module's builtin – zpopulator. I was counting on: Zsh will think
module command ended because main thread will do "return 0", it will not
break the pipe because it gets broken by itself when reader or writer
exits. This way the forked "print -rl" and the thread-splitted
"zpopulator" could work in background. However I just discovered that:

# ls -R / | zpopulator -D , -vA myhash

DOES block shell.. I successfully obtained no-block behavior but it was
zpopulator that was persisting, not the writing process (forked one). 

Have you any idea how to cause above to not block shell? zpopulator's
thread exits from module's builtin, this should be close to unblock
shell..

Code:
https://github.com/psprint/zpopulator/blob/41f40f7b35c67fed907d660b620f4ec5bda6022e/module/Src/psprint/zpopulator.c#L438-L442

-- 
Sebastian Gniazdowski