<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 10:55 AM, Mariano Martinez Peck <span dir="ltr"><<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr">Hi Eliot,<div><br></div><div>Ok, I started from the first step and I am able to type a C program that would export the STON I need. </div><div>This is all hardcoded for the moment and not autogenerated.</div><div>The question I have now is....do you think I should use "cmake" for managing the compilation of this C program (later to be autogenerated) ???</div><div>If not, what other choice I have?</div></div></blockquote><div><br></div><div>Cmake is overkill. You only have to compile one file with very simple flags. So for now use the old OSProcess (or compile manually) but... once you have your own OSProcess then the right way is to compile it using your new OSProcess. You have to require that the user put the C compiler in their path, but everything else you have in the pragmas. e.g. you're only doing</div><div><br></div><div>cc -m32 -o MYSQLInterface.mac32 MYSQLInterface.mac32.c</div><div>./MYSQLInterface.mac32</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks!</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 18, 2016 at 10:16 AM, Dimitris Chloupis <span dir="ltr"><<a href="mailto:kilon.alios@gmail.com" target="_blank">kilon.alios@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr">ah ok now its crystal clear thanks for the explanation. <br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 18, 2016 at 3:11 PM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div dir="auto"><div>Hi Dimitris,<br></div></div><div dir="auto"><div><br>On Jan 18, 2016, at 4:11 AM, Dimitris Chloupis <<a href="mailto:kilon.alios@gmail.com" target="_blank">kilon.alios@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr">AFAIK OS thread are capable of being assigned to multiple cores thus offering real concurency, thus I presume your native threads are not OS threads. So the VM run on one thread but can communicate with other threads ? Does that apply to multithreaded VM ?<br></div></div></blockquote><div><br></div></div><div dir="auto">As I said these /are/ native OS threads. The VM arranges that only one native thread can run the VM at any one time. The owning thread locks out other threads. The VM makes an FFI call out on one OS thread which unlocks the VM just before calling out and if that callout takes enough time for the heartbeat thread to beat then another thread will be released to try and lock and run the VM. If it wins the race the other call out thread will block when trying to rhea quire the VM to return it's result.<div><br></div><div>So this is real multi threading without concurrency as I said.</div></div><div dir="auto"><div><br><div><br><blockquote type="cite"><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 18, 2016 at 2:02 PM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div dir="auto"><div>Hi Dimitris,<br></div></div><div dir="auto"><div><br>On Jan 18, 2016, at 3:29 AM, Dimitris Chloupis <<a href="mailto:kilon.alios@gmail.com" target="_blank">kilon.alios@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div>so I assume that means callbacks from inside C threads works fine which make it more than enough at least for now. <br></div></div></div></blockquote><div><br></div></div><div dir="auto">C threads us a misnomer. Callbacks from native threads that are currently calling out work. I /think/ callbacks from native threads that have previously called out but are not currently calling out work, but am not sure. Callbacks from native threads the VM has not seen before don't yet work; the VM doesn't service them.<div></div></div><div dir="auto"><div><br><blockquote type="cite"><div><div dir="ltr"><div>Does that mean that the VM will implement a real threading mechanism ? </div></div></div></blockquote><div><br></div></div></div><div dir="auto"><div>This is a mechanism that allows one to freely share the VM between arbitrary native threads but only one thread can run the VM at any one time. So it provides true multi threading but it does /not/ provide concurrency.</div></div><div dir="auto"><div><br></div><div><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Mon, Jan 18, 2016 at 1:11 PM Craig Latta <<a href="mailto:craig@netjam.org" target="_blank">craig@netjam.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
> ...when Craig Latta tried to use [Alien FFI] late last year it worked<br>
> up to a point. The thing that didn't work was callbacks from foreign<br>
> threads. So it looks like the core threading code is not too far<br>
> away from working.<br>
<br>
(Yes, it seemed close enough that I spent several hours debugging,<br>
trying to get it the rest of the way. I ran out of time, so I wrote a<br>
wrapper C library around the one I wanted to use, with threaded C<br>
callback functions that signalled Smalltalk semaphores on which my<br>
synchronous-FFI Smalltalk process waited. A hack, but it worked fine and<br>
was simple.)<br>
<br>
<br>
-C<br>
<br>
--<br>
Craig Latta<br>
<a href="http://netjam.org" rel="noreferrer" target="_blank">netjam.org</a><br>
+31 6 2757 7177 (SMS ok)<br>
<a href="tel:%2B%201%20415%C2%A0%20287%203547" value="+14152873547" target="_blank">+ 1 415 287 3547</a> (no SMS)<br>
<br>
</blockquote></div>
</div></blockquote></div></div></blockquote></div>
</div></blockquote></div></div></div></blockquote></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br></div>
</div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>