2012/5/6 Igor Stasenko <[email protected]>: > On 5 May 2012 18:00, Eliot Miranda <[email protected]> wrote: >> >> >> On Fri, May 4, 2012 at 6:23 PM, Igor Stasenko <[email protected]> wrote: >>> >>> Hi, David, all >>> >>> i just want to know, if we can use FFI calls, for implementing an >>> OSProcessPlugin functionality (or at least most of it). >>> and if there parts which is hard to implement, i would like to know >>> what and why. >> >> >> Once we have the threaded FFI and the threaded VM then yes, because one can >> block one thread in a read without blocking the entire VM. But without the >> threaded VM one needs asynchronous i/o. >> > yes, but nobody said, that i can't use non-blocking i/o. > > the main advantage which i see for using FFI is being able to deal > with everything at language level. > so, bugs can be fixed quickly, things can be improved more easily etc etc.. > and the main disadvantage is, of course, speed. >
No. The main disadvantage is to expose the complexity of outside world at user face, when it was once hidden under the VM carpet. In the VM, complexity is handled with the "right tools" (cough...) #include machine_specific_stuff.h driven by #ifdef why_the_hell_is_it_so_complex ;) and include paths library paths ldconfig etc... It's of course cough-able because this complexity then spread into m4 macros for configure scripts and other such niceties. Sure, - when the VM is not able to handle outside world zoo because a lack of manpower, and because the outside world changed too fast while we were sleeping happy in our mickey world, - or if we want more than least common denominator between several underlying platforms, then yes, it might be better to adopt your strategy, because we can get more manpower at image level than at VM level... However, it's a kind of pact with the devil: we get the power at the price of introducing the #ifdef hell in the image. Sure, with a good object model, we might think that it will be easier to handle such complexity. But then we're just ignoring the efforts of hordes of programmers maintaining this shit, and redo all in image. I'm not sure that it will be sustainable... Unless of course we focus on a single platform. Your work is very important, because at least, it will enable powerful single platform extensions. But as you see, I just wonder how it would help us to continue providing ubiquity... Nicolas >>> >>> If you want to ask, why one would want to do this.. the answer is simple: >>> we stated previously, that we want to reduce the VM complexity by >>> implementing things at language side, when it possible, >>> leaving only key parts to VM. >>> This is the main reason why i consider implementing OSProcess using >>> purely FFI, not because of quality of OSProcessPlugin >>> implementation etc. >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> best, >> Eliot >> > > > > -- > Best regards, > Igor Stasenko. >
