Re: Multithreading support in pluggable module, but with problems

[Bart Schaefer <schaefer@brasslantern.com>]

On Feb 11,  4:58am, Sebastian Gniazdowski wrote:
} Subject: Multithreading support in pluggable module, but with problems
}
} # zpin 'print -rl "a:b" "c:d"' | zpopulator -A my_hash
} 
} This is done entirely in background. zpin does fork() and this way makes
} Zsh think it's finished - main process exits. zpopulator starts a thread
} and makes main thread exit - this is also sufficient to make Zsh think
} that there is no background job.

So if I understand this correctly, you're attempting to use POSIX threads
to share the my_hash variable between the main shell and a 2nd thread of
which the main shell is not aware, so that the 2nd thread can stuff a
value into my_hash while the main thread goes on about its business?

I can almost promise you there is no way to make that work, at least not
in a crash-proof manner.  Even making my_hash PM_READONLY -- which is I
presume what yesterday's question was about -- what is there to stop
the thread-unaware main shell from accessing it at a time when the 2nd
thread is changing it in some way that will send the main thread off
into uncharted memory?

Aside from that, you're running directly afoul of the presecribed
behavior of file descriptor management for shells, which amounts
to a prohibition on passing unexpected file descriptors down to any
forked children.  If you want to keep a descriptor around, you have
to manipulate it with the routines in Src/utils.c that manage the
fdtable array.

In particular you *might* need to call either movefd() or redup()
rather than call dup2() directly, and you should otherwise be using
addmodulefd() to protect the fd from exec.c:closeallelse().  Examples
in Src/Modules/tcp.c.