[Vm-dev] VM on Solaris (was: Camera sig fault on 64 bits machines.)

[Andreas Wacknitz]

Thanks again Eliot,

First, I solved the pthreads problem under OpenSolaris. While Solaris 10 doesn’t need special user privileges for thread control (at least within the same thread policy I guess),
users under Solaris 11 (and thus OpenSolaris) need the privilege „proc_priocntl“ to be given by an administrator.
(For those who are interested: usermod -K defaultpriv=basic,proc_priocntl andreas)

More below…

Am 22.04.2014 um 22:31 schrieb Eliot Miranda <eliot.miranda at gmail.com>:

> 
> 
> 
> On Tue, Apr 22, 2014 at 1:10 PM, Andreas Wacknitz <a.wacknitz at gmx.de> wrote:
>  
> 
> Am 22.04.2014 um 21:36 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
> 
>> Hi Andreas,
>> 
>> 
>> On Tue, Apr 22, 2014 at 12:05 PM, Andreas Wacknitz <a.wacknitz at gmx.de> wrote:
>> 
>> This evening I further dealt with the problems on OpenSolaris (openindiana).
>> I finally got a pthread version running without superuser rights. But I don’t know whether this will really work (ATM it does for me)
>> because I removed the call to pthread_setschedparam in beatStateMachine leaving the heartbeat thread with the same
>> priority than the vm thread.
>> 
>> Alas, that will not work -(.  As soon as the image enters into a hard loop (e.g. [true] whileTrue) the heartbeat thread will be blocked and the VM will never break out of the loop.
> 
> How can I check this blockage? I started the VM with --pollpipe 1 and then [true] whileTrue in a Workspace. The GUI is blocked but the pipe is still rotating.
> 
> Can you interrupt with ctrl-period?  If not, then I don't understand how the pip is still rotating :-).  If you can, then you're not blocking the system.  Try e.g. [[true] whileTrue]  forkAt: Processor highestPriority.
Yes, I can do that in both (with and without higher priority) BUT not when running this with highestPriority (again in BOTH versions!).

> 
> You are running the JIT right?
How to tell for sure? I started the VM with —trace. The last log is „IRBytecodeGenerator>>from:goto“.
The pipe is still rotating but ALT-. does not break the loop (maybe a problem of my Pharo image?; I will try later with a Squeak image).

> 
>> I tried to replace the pthread_setschedparam call with a similar pthread_setschedprio call but
>> with no luck (same problem: failed call with "Not owner"). I don’t know wether this is a general problem with the pthreads implementation
>> on Solaris or just a problem with the gcc version (4.4.4) coming with the openindiana distribution I am using. Maybe this works only
>> with the compilers and libraries that is delivered by Oracle (Solaris 10 ships with gcc 3.4.3; Solaris Studio has its own compilers).
>> 
>> It's too do with pthreads.  Nothing to do with the compiler.  On some implementations it requires special permission to create threads with different priorities.  That used to be the case on linux and it appears to be the case on OpenSolaris.  Hence one is stuck with the itimer heartbeat.
> Is there any implementation actually using sqUnixITimerHeartbeat.c?
> 
> Yes, but unhappily.  We use it at Cadence because we have customers on pre 2.6.12 kernels.  We have to e.g. switch off the heartbeast around certain external calls.
I am still wondering about where the necessary sleep call will be generated in this case. I will check your latest VM sources. Maybe PharoVM is different here…

>  
> I don’t think that Solaris has special problems here.
> Also, I cannot imagine that this situation is so uncommon that nobody else got it before SqueakVM. A higher prioritized thread should be possible for ordinary users.
> 
> I definitely wasn't the case on linux.
> 
I haven’t tried to build the VM for Solaris 10 yet but I have tried a multi-threaded example program I found in the web. This example program is running 4 threads for computation
and does not run under OpenSolaris (same error code like the SqueakVM is generating) but it runs without hassles on Solaris 10 SPARC. So I guess Solaris 10 will run the
two-threaded SqueakVM without problems.


Best regards,
Andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140423/2881c1bf/attachment-0001.htm