Hi Robert,
You are using tmp_errno = errno... ret is precisely holding errno. I
have built the native-lib so that we are always thread safe. I have not
noticed that VMChannel is so native-lib agnostic. ;-) I will have to
rewrite VMChannel... Probably next weeks will be devoted to this.
In respect to this buggy interface, it is ok. :)
Cheers,
Guilhem.
Robert Schuster wrote:
> Hi all,
> the title looks like fun, eh? :)
>
> In an attempt to get gnu/testlet/java/net/ServerSocket/ReturnOnClose to
> succeed
> on Cacao with the new an shiny VMChannel implementation I found out the
> Cacao's
> Thread.interrupt() does not cause blocking system calls to be interrupted. A
> short glimpse a GCJ's code (where the above testcase runs fine) revealed that
> I
> needed to add a pthread_kill (and an obligatory sigaction) to get things
> working.
>
> With that in place I tried to implement a correct VMChannel.accept. The
> interesting part looks like this:
>
> do
> {
> ret = cpnio_accept (fd, (struct sockaddr *) &addr, &alen);
> tmp_errno = errno;
>
> /* Check if interrupted by Thread.interrupt(). If not then some
> * other unrelated signal interrupted the system function and
> * we should start over again.
> */
> if (tmp_errno == EINTR && JCL_thread_interrupted(env, clazz))
> {
> JCL_ThrowException (env, "java/net/SocketException", strerror
> (tmp_errno));
> return -1;
> }
> }
>
> while (ret == -1);
>
> if (ret == -1)
> {
> if (EWOULDBLOCK != tmp_errno && EAGAIN != tmp_errno)
> JCL_ThrowException (env, "java/net/SocketException", strerror
> (tmp_errno));
> }
>
> return ret;
>
> tmp_errno is an int which is set to 0 in the beginning.
>
> The special bit is JCL_thread_interrupted which calls back into the VM
> to ask it whether the current thread has its interrupted flag set. My idea is
> that a delibarate Thread.interrupt() from inside the VM should stop
> VMChannel.accept() while a user running: "killall -SIGUSR1 cacao" from the
> console should not.
>
> Is that implementation OK. If not please give me some pointers to make it
> better.
>
> cya
> Robert
>
