I think that this project would be good test-bed for testing a non-blocking FFI callouts.
On 4 October 2010 23:23, Levente Uzonyi <[email protected]> wrote: > On Mon, 4 Oct 2010, Sven Van Caekenberghe wrote: > >> Noury, >> >> One of the other aspects that I find important is elementary efficiency. >> >> A lot of stream related code in Smalltalk is not efficient, the actual >> data is copied around like crazy, turning it from a stream to a collection >> and then back into a stream multiple times. For Zinc HTTP Components I made >> a lot of effort to make it possible to read data from a socket stream in >> true streaming fashion (instead of just returning a byte array). Now, the >> idea was then that for example JPEGReadWriter>>#nextImage would work >> transparaently on that raw stream. Sadly, the code in JPEGReadWriter and >> friends just reads everything into an array before it starts to work ! >> >> Doing a #nextPutAll: <some byte array> should really try never to copy the >> array. Similary, a #next: <count> into: <some byte array> should similary >> write directly into the given array. What I see in the current SocketStream >> is <censored/> ;-) > > This is why we implemented our own SocketStream in PostgresV3. > >> >> But OK, maybe this is easier said than done. The step from Smalltalk to >> system call should also not copy if that is possible, but then FFI and GC >> come into play. > > I wonder if there's a language, that provides socket access via FFI. > > > Levente > >> >> Anyway, good luck, I am willing to try using Ocean as soon as it becomes >> available. >> >> Sven >> >> On 04 Oct 2010, at 10:59, Noury Bouraqadi wrote: >> >>> >>> On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote: >>> >>>> For Ocean to succeed, you either have to work really hard to make >>>> non-blocking calls (I'm thinking of SSL sockets), or you need the ability >>>> to >>>> call functions on OS threads. The calls need to block their calling >>>> Process >>>> and let the other Processes run as though nothing is happening. >>>> >>> You're right. >>> Another option is having a multi-threaded VM. Eliot seem to work on it. >>> So far we're working on cleaning up the design of basic functionalities >>> before going on. >>> Then, we'll try to find a workaround for non-blocking calls. >>> All ideas are welcome :-) >>> >>> BTW, some people (you included) proposed to help for the Ocean project. >>> Luc and I want to thank you and we are happy that others are willing to >>> help. >>> We thought about the best way to integrate others help. >>> Our conclusion is that we should first do alone (luc and me) the >>> reference design, before integrating other developers. >>> So, we all can work on solid foudations. >>> >>> Noury >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
