Hi Esteban,

regarding the threaded versus itimer vm, I guess OSProcess would be
affected as well? And also, how to get the threaded vm with zero-conf or
files.pharo.org?

Regards,

Thierry

2017-03-13 8:00 GMT+01:00 <[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
>
> 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
>     ----
>
>     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
>
>

Reply via email to