[Ecls-list] Threads and signal masks

[Matthew Mondor]

On Sat, 6 Aug 2011 22:50:20 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> CATCH-SIGNAL is expected to rule what ECL does with external interrupts and
> it should work in systems that do not implement full POSIX, such as Windows
> -- where we rely only on signal() at the moment but might be extended to the
> exception handler.
> 
> I have uploaded some updates to ECL, described in this excerpt from
> CHANGELOG.
> 
>  - Each thread keeps a copy of the process sigmask (POSIX) and it is
> inherited
>    by children thread. The sigmask can be manipulated by the function
>    EXT:CATCH-SIGNAL which has the signature
> (ext:catch-signal signal-code action &key process)
>    The ACTION is one of :IGNORE, :DEFAULT, :CATCH, determining what ECL does
>    when it receives the signal, or it can be :MASK/:UNMASK to determine
> whether
>    the process is blocking the signal or not. The optional argument :PROCESS
>    only applies to :MASK/:UNMASK and it can be the current process, some
>    process that has not been activated or any other value (indicating that
>    the function has a global effect, as sigprocmask).
> 
> As I said, it goes a bit beyond what you submitted, maintaining an interface
> that dates back to KCL and still working with multithreaded environments.
> Limited testing suggests that it works.

Oh, I see.

So I reviewed the changes (after some minor gripe with the way git
handles conflicts, I still consider myself new to it), and it seems to
be good.  I found the place dealing with process_t somewhat tricky but
I think I understand.  As you say, the default signal mask for a thread
might be changed by providing a wanted process/thread, which if is the
running one also causes thread_sigprocmask(3) to be called.  If T is
supplied then sigprocmask(2) is called instead.

I think that the new interface is allright for my needs.
Unfortunately I could test it yet though, the code doesn't build and I
failed to immediately see why the proprocessing was not done properly
for that function:

dpp: /home/mmondor/work/ecl-git/ecl/src/c/unixint.d -> tmp.c
gcc -DECLDIR="\"/usr/local/ecl/lib/ecl-11.1.1\"" -I. -I/home/mmondor/work/ecl-git/ecl/build -I/home/mmondor/work/ecl-git/ecl/src/c -I../ecl/gc -DECL_API -DECL_NO_LEGACY   -I/usr/pkg/include -march=i686 -O2 -g -fPIC  -Dnetbsd -c -o unixint.o tmp.c
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d: In function 'mysignal':
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d:212: warning: comparison of distinct pointer types lacks a cast
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d:212: warning: comparison of distinct pointer types lacks a cast
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d:213: warning: assignment from incompatible pointer type
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d: In function 'do_catch_signal':
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d:675: warning: passing argument 2 of 'mysignal' from incompatible pointer type
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d:678: warning: passing argument 2 of 'mysignal' from incompatible pointer type
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d: At top level:
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d:737: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d: In function 'install_asynchronous_signal_handlers':
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d:1100: warning: passing argument 2 of 'mysignal' from incompatible pointer type
/home/mmondor/work/ecl-git/ecl/src/c/unixint.d:1101: warning: passing argument 2 of 'mysignal' from incompatible pointer type
*** Error code 1

Where in build/c/tmp.c:

#line 737
cl_object ext::catch-signal(cl_narg narg, cl_object code, cl_object flag, ...)
{

Perhaps a result of the :: in the function name?

Thanks,
-- 
Matt