Re: threads status update

[Ivan S. <iv...@gm...>]

On Thu, Feb 18, 2010 at 10:07 AM, Vladimir Tzankov <vtz...@gm...> wrote:
> Another issue is FFI: modifications of global variables involved are
> not synchronized. Also I would like to handle foreign threads
> callbacks (when foreign code creates thread and callbacks from it in
> lisp - in this case there is no clisp_thread_t associated with this
> thread).

Let me chime in on the subject. It may seem that using global freelist can be
avoided in trampoline_r code by using malloc(), but actually using
malloc()+mprotect() is incorrect. The standard here
http://www.opengroup.org/onlinepubs/9699919799/functions/mprotect.html
says concerning mprotect() usage:

The behavior of this function is unspecified if the mapping was not
established by a call to mmap().

The memory obtained from malloc() may come from brk(). On some platforms,
including Linux armel (tested on Maemo Fremantle), this may yield memory
on which mprotect() seems to be silently failing.

(I've run into more callback issues on Maemo in case when ffcall
is built as a set of shared libraries, and I'm currently trying to find time
to investigate them, so I didn't make updated patches for Maemo
support yet.)

Ivan