<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 18 Apr 2015, at 19:36, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="auto"><div>Hi Stef,<br><br></div><div>On Apr 18, 2015, at 10:13 AM, stepharo <<a href="mailto:stepharo@free.fr">stepharo@free.fr</a>> wrote:<br><br></div><blockquote type="cite"><span></span></blockquote><blockquote type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
I think that the idea of eliot is independent from NB but use FFI.<br>
Esteban will resume his task to use NB syntax for FFI and NB as a
back-end of the UnifiedFFI.<br></blockquote><div><br></div>I hope we can revise this slightly to agree with the back end that Ronie, Clément and I propose, which is to use the unsafe bytecodes in Sista/Scorch to include Ronie's lowcode and do the marshaling, avoiding NB. This gives us platform independence, the ability to function in the interpreter (the Sista interpreter can execute these bytecodes too), and security, since when jitted the code lives in the code zone which we can secure, and avoid making the whole heap executable. Maybe you can discuss with Clément when he returns.</div></blockquote><div><br></div>yes we do not want to be bound to NB. (what I menat with NB as a back-end of the UnifiedFFI was that if people want to use NB as a back-end they should be able to do it).</div><div>If Igor maintains it and port it to 64 bits we do not want to be against. </div><div>What we need is a version of FFI that understand NB syntax running so that we can ship Spur.</div><div><br></div><div>Stef</div><div><br><blockquote type="cite"><div dir="auto"><div><br><blockquote type="cite">
<br>
Stef<br>
<br>
<div class="moz-cite-prefix">Le 18/4/15 18:24, Nicolai Hess a
écrit :<br>
</div>
<blockquote cite="mid:CAPED3SS5xx83=0OaV2t4iPtwPNn7Q7HjdoYvQFOvJcHPT0iXww@mail.gmail.com" type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<div dir="ltr">Thank you Esteban,<br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-04-18 9:36 GMT+02:00 Esteban
Lorenzano <span dir="ltr"><<a moz-do-not-send="true" href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
<div style="word-wrap:break-word">Hi,
<div><br>
</div>
<div>So… “multithread” is a complicated issue. Pharo
as most Smalltalks is designed thinking is as
monolithic so if you are trying to make the image to
work in different processes… it will not be easy at
all :)</div>
<div>Time ago Eliot did a prototype (more than a
prototype in fact, but still far from “production
ready”) to have Threaded FFI and I’m quite sure this
is the way to go, at least as a 1st milestone. </div>
<div><br>
</div>
<div>I already have a process building this
experimental VM:</div>
<div><br>
</div>
<div><a moz-do-not-send="true" href="https://ci.inria.fr/pharo/view/VM/job/CogMTVM/" target="_blank">https://ci.inria.fr/pharo/view/VM/job/CogMTVM/</a></div>
</div>
</blockquote>
<div><br>
</div>
<div>But this one does not include NativeBoost support. Do
we have a build with MT and NB?<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><br>
</div>
<div>(No idea why windows build failed last two times…
this can be a random fail).</div>
<div><br>
</div>
<div>I do not remember exactly the changes needed in
the image to take advantage of it… it was just an
instVar in Process, I think, but then FFI package
was adapted to take advantage of this… no idea where
it is now (if is already incorporated in latest FFI,
which we have).</div>
<div><br>
</div>
<div>Then, after this… I imagine the callback
mechanism can be adapted to work in multithread
environments but probably we will need something
like isolates from Dart to provide some degree of
multithread processing without killing the image
(but I’m just thinking in loud here, this can be a
really bad idea, and probably there are other ways
to do this better… I will let Eliot to explain
better). </div>
<div><br>
</div>
<div><b>TL;DR: </b>Start for the CogMTVM, is the way
to go.</div>
<div><br>
</div>
<div>cheers, </div>
<div>Esteban</div>
<div><br>
<div>
<blockquote type="cite">
<div>On 17 Apr 2015, at 09:06, Nicolai Hess <<a moz-do-not-send="true" href="mailto:nicolaihess@web.de" target="_blank">nicolaihess@web.de</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hi, <br>
<br>
</div>
I've tried to
build a pharovm
with multithread
support. I changed
the config in the
<br>
</div>
pharo
generator.image to
use the cogmt config
and was able to
build a vm.<br>
</div>
But this vm crashes on
startup. (windows7)<br>
<br>
Is this the right way
and did anyone got
this to work (windows
or linux)?<br>
<br>
</div>
And can this work to
make NB callbacks
working for
multithreaded libraries.<br>
</div>
<br>
(I made some simple
bindings for the gstreamer
lib with NB, this works<br>
</div>
for simple calls (create
element/change state). But I
guess this won't work<br>
</div>
for any gstreamer function
that requests a callback that
may b e called from<br>
</div>
a different thread)<br>
<br>
</div>
Would this be the right way to do:<br>
</div>
- build a vm with MT support<br>
</div>
- guard the NB callback entry/leave
code with the ownVM()/disownVM() call.<br>
<br>
</div>
Or is there more to do.<br>
<br>
</div>
<div>Thanks in advance<br>
</div>
<br>
<br>
</div>
nicolai<br>
<div>
<div>
<div><br>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</blockquote></div></div></blockquote></div><br></body></html>