I have actually received a few donations! I'd like to start by saying thank you, you know who you are!
After a much needed vacation on the French Riviera, I still have a few days off work, and I can put a wee bit more effort into JAmiga/JamVM.
As previously stated I'm focused on JamVM. I've just switched from version 1.5.3 to the latest Git-hub version which have all the OpenJDK stuff and new shiny features. I had to make the switch since, a) its the wise thing to do; why bother with old stuff, and b) I stumbled upon the same JNI function that wasn't implemented in the JAmiga VM (*sigh*).
Things we miss in AmigaOS 4 land which makes porting harder
Automake/autoconf etceteraCurrently I'm moving my 1.5.3 changes to the new JamVM, and trying to sort out the makefiles. Which is tedious, boring and I suck at it. JamVM uses Makefile.am which should be automake'd with tools we don't have for AmigaOS (at least I haven't found them in the usual channels). So I'm doing it by hand. Which isn't that hard. Just boring and time consuming.
This is basically done now -- I'm not entirely happy having the makefiles manually tweaked, but it was the most pragmatic solution for the time being.
- sigaction() This function
- pthread_sigmask() From the man-page:
- sigsuspend() The docs says that
allows the calling process to examine and/or specify the action to be associated with a specific signalaccording to the docs.
This is used in JamVM's initializeSignals() to setup the suspendHandler() function being called when SIGUSR1 is signaled to the thread. I have changed this to instead use IExec->SetExcept(), to call the same function upon receiving SIGUSR1.
The pthread_sigmask() function shall examine or change (or both) the calling thread's signal maskThis does the same thing as the function sigprocmask(), but only for one thread. The latter we actually have in clib2's signal.h. We probably don't have it in pthread implementation, since it seems to be using some sort of signaling which AmigaOS don't support by standard.
But what does it do exactly? It is used in JamVM in the functions enableSuspend() and disableSuspend() (and their variations). For enableSuspend the SIGUSR1 signal is unblocked (SIG_UNBLOCK), and for disableSuspend it is blocked (SIG_BLOCK) -- i.e. when suspend is enabled, the thread will be able to receive the SIGUSR1 signal, and when disabled not. This has impact on the sigaction stuff just mentioned, so my theory is that I will be able to again call IExec->SetExcept() and disable/enable the SIGUSR1 exception catching in enableSuspend and disableSuspend, respectively.
sigsuspend() replaces the current signal mask with the set of signals pointed to by sigmask and then suspends the thread until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process
This is used in the JamVM function suspendLoop(), which is called from enableSuspend() and suspendHandler(). The suspend loop suspends execution until any signal, except SIGUSR1 and SIGTERM (these are removed from the mask using sigdelset prior the call) is sent to the thread, while the JamVM thread flag "suspended" is true (JamVM:s internal structure for its threads). Basically the thread is suspended until signalled not to be.
I think this could be interchanged with a Wait() on the appropriate signals. If a SIGTERM is sent to the thread, I'm guessing the thread should be terminated... but on the other hand, the signal mask given to sigsuspend has SIGTERM explicitly unset. I'll have to experiment with this, and investigate further.
We (AmigaOS 4 users) do actually have the shared library thread.library which implements most of the pthread functionality, however not the pthread_sigmask (as described in the Signal section above), and these functions:
- pthread_kill() AmigaOS can't "kill" a process. We could ask it (by sending Ctrl-C or something), but that's not the same thing. So for now this a dummy function that does nothing implemented by me.
sched.hWe don't have the sched.h include, and thus not these JamVM needed functions:
- sched_yield() According to docs, this
forces the running thread to relinquish the processor until it again becomes the head of its thread list.
I believe that this can in some way be interchanged with SetTaskPri(FindTask(NULL), 0), which "changes priority of a task [and] a reschedule is performed", where the important part being the rescheduling. I have heard that we really can't trigger an explicit rescheduling in AmigaOS (with the pre-emptive multitasking, I assume), so this is the closest we'll get.
I will be implementing and testing my theories above. In a future blog I will report more thoroughly on my chosen methods to implement the missing functionality found. Hopefully this can be of use for other porters in Amiga land.
Again, I wish to thank for the donations. If anyone else wan't to donate, the button is at your right. I have been thinking of starting a bounty, but I currently don't know what to expect from my efforts. But I want you all to know that I won't give up until I can run Eclipse and other java stuff on my Amiga, perhaps not mainly on my AmigaONE XE, but more likely (time wise) on my X1000 (which I hope will come before the end of the year).