> On 13 Mar 2017, at 10:10, Thierry Goubier <[email protected]> wrote: > > Hi Esteban, > > regarding the threaded versus itimer vm, I guess OSProcess would be affected > as well?
yes > And also, how to get the threaded vm with zero-conf or files.pharo.org > <http://files.pharo.org/>? you don’t. I have in my todo to add threaded VMs to zeroconf. I will try to handle that today-tomorrow. Esteban > > Regards, > > Thierry > > 2017-03-13 8:00 GMT+01:00 <[email protected] <mailto:[email protected]>>: > Hello! > > This is my weekly ChangeLog, from 6 March 2017 to 12 March 2017. > You can see it in a better format by going here: > http://log.smallworks.eu/web/search?from=6/3/2017&to=12/3/2017 > <http://log.smallworks.eu/web/search?from=6/3/2017&to=12/3/2017> > > ChangeLog > ========= > > 10 March 2017: > -------------- > > * === libgit2(ssh) and linux > An update on the libgit2 (and consequently iceberg) problem on linux: SSH > will not work on ITIMER VM (which > is the zeroconf default, at least for now). > > Here the reason: > > ITIMER sends an signal to the VM thread using +pthread_kill(tickerThread, > TICKER_SIGNAL)+ and that aborts > system calls, which are used by +libssh2+, producing a 'wait for packet' > to fail answering a timeout ( > even if that timeout does not happens for real). > > Here is an interesting comment from +sqUnixITimerTickerHeartbeat.c+ : > > ---- > /* While we use SA_RESTART to ensure system calls are restarted, this is > * not universally effective. In particular, connect calls can abort if > * a system call is made in the signal handler, i.e. the pthread_kill in > * prodHighPriorityThread. So we avoid this if possible by not prodding > * the high-priority thread unless there are high-priority tickees as > * indicated by numAsyncTickees > 0. > */ > ---- > > ... and sadly, as +OSSubprocess+, +libssh2+ calls falls under the > category of "not universally effective" > (they are connect calls... once disconnected, you cannot connect again > 'as is'). > > So, the only workaround possible (at least for now), is to use the > threaded version of VM... I improved the > error message it throws when this fails, now looks like this: > > ---- > This VM uses a thread heartbeat who requires a special configuration to > work. > You need to allow it to run higher priority threads (real time), to allow > clock to work properly > You need to add a conf file to /etc/security/limits.d, executing this: > > sudo cat >/etc/security/limits.d/%s.conf <<END\n", VMNAME); > * hard rtprio 2 > * soft rtprio 2 > END > > You need to log out and log back in for the limits to take effect. > For more information read > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux> > ---- > > which at least shows what's happens and how you can easily fix it. > > Now, I think this is a *sad solution*. Needing to touch system > configuration in order to run a VM > does not feels "professional". I would like to have some time to find a > fix. > > > 9 March 2017: > ------------- > > * I spent last two days again fighting with linux dependencies, because > what I thought was fixed (the > loading of +libgit2.so+), actually was not working in all conditions. > > Now, I think I finally arrived to a working solution (that involved add > an +rpath+ to Pharo, not > to dependent libraries). > > There is a new +vmLatest60+, let's see how it works... > > > 6 March 2017: > ------------- > > * I spent time fixing libgit2 (and dependents) compilation, both for linux > and windows. > > As a result, now windows is working again (there was problems after > version 0.26)... but linux, who seemed > working last friday, is now again not working properly :( > > > cheers! > Esteban > >
