> --- >> >1) It must always test results of its internal operations, such as >> > malloc, and return error. lua simply exit()s when memory is over. >> >> http://www.nekovm.org/doc/ffi#managing_memory > > There's no mention how neko tests results in its internals. > --- > > I think this will be handled by GC but what happens?! > > 1.) Exceptions > 2.) Segfault, I don't think so ;-) > 3.) ???
In case of out-of-memory, the GC display an error message and then the VM exits. In case of segfault, the app crashes on windows but for some signals on Linux (Bus Error) a Neko exception is thrown. This makes things more easy for debugging. > --- >> >3) It should support non-blocking oprations, such as >> > >> > v = get_variable(...) >> > if (v == NOT_READY) ... > --- > > I think this could be done with threads but I'am not sure. Yes, threads is one possibility. But testing the NOT_READY state can only be done within a CPU-consuming loop, which is pretty bad. The best is to have threads communicate through messages. For example one thread send a message to a worker thread, then waits for its answer. > There is a server which handles http-requests and should not be blocked > during neko works on his task. You can either use threads or socket_select with async sockets to perform multiplexing. The best is to combine both techniques. That's what is doing for example the haXe neko.net.ThreadServer class which is based on neko sockets and threads. Nicolas -- Neko : One VM to run them all (http://nekovm.org)
