newLisp multi thread in Windows

[ale870]

Hello,



is there any way to use multi-thread in newLisp in Windows?

I know there are some specific functions, but it seems they make real multi thread only under Linux.

And for Windows?



Thank you!

[ale870]

No multi thread for windows?

[m35]

I don't think it's possible to do Windows multi-threading in newLISP. If I understand Windows multi-threading correctly, newLISP would have to start a newLISP evaluator in every thread. Of course that's not how newLISP is currently designed.



You could try, from newLISP code, to call Win32 API commands to start a separate thread and give it a newLISP callback function. However, the same code evaluator would be used in two different threads at the same time, and it would probably just crash.



AFAIK the best you can currently get is to start multiple newLISP processes and have them communicate via some sort of IPC.



I know Lutz added the cilk API, but I haven't looked into how that plays into all this on Windows.

[ale870]

Thank you.

I already use newLisp with multiple processes, but the problem is each process is completely separated from the other ones. Instead using threads I can manage multiple instances with shared memory data.

I was imagine that if a multithread version exist for Linux then I think there is a way to implement it in Windows too...

[Lutz]

Actually you can use shared memory on Windows between processes, but you willl run into a blocking situation again when coordinating the memory sharing with semaphores. On Unix you can query the state of a semaphore on Windows you only can wait/block on it.



I think the only solution on Windows (if you cannot solve the peek problem) is, to invent some kind of protocol between the processes, which can avoid blocking, or you goto Tcp/Ip communications with net-select/net-peek to avoid blocking.

[ale870]

Thank you Lutz, your information are really clear.

Now I better understand what's the problem at "low-level".

I didn't know such details about Unix vs Windows.

My only doubt is it seems you are talking about multitasking using processes, and not using threads.

I know that Windows uses much better the threads than the processes (instead Unix-like OS do the opposite: using "fork" they work really well with processes, and only in "recent" times they are using threads because they are lighter).

Windows threads can be managed very well, and "queue effect" (one request behind another one, serialized) is applied only for common resources access (like variables, memory area, etc...). In that case I think is correct that one thread locks the resource and another thread will wait the first thread.

[Lutz]

newLISP forks are very light and speedy because of newLISP's small size. There is a Windows fork implementation by Cygwin, and a few years back the Windows version of newLISP  was compiled on Cygwin. Unfortunately the fork implementaion on Cygwin was not very stable. Because of this and other reasons newLISP went from Cygwin to MinGW for the Windows version a few years back.

[ale870]

Ok, I see.

Thank you Lutz!

[pjot]

You can also try to use my 'winfork' from here:



http://www.turtle.dds.nl/newlisp/winfork.lsp">http://www.turtle.dds.nl/newlisp/winfork.lsp

Code Select Expand


(context 'winfork)

# Capture newLisp internal symbols
(constant 'winfork_SYMBOLS (symbols 'MAIN))

# Setup environment for FORK
(define (winfork:winfork winfork_ARG)

# Let the total result start with 'silent'
(set 'winfork_ENV "(silent ")

# Get all the user-defined symbols
(context 'MAIN) ; only required for v.8.8.0 for 'source'
(dolist (winfork_VAR (difference (symbols MAIN) winfork_SYMBOLS)) (write-buffer winfork_ENV (source winfork_VAR)))

# Append the actual forked function
(set 'winfork_ENV (append winfork_ENV ")" (string winfork_ARG)))

# Replace existing double-quotes
(replace {"} winfork_ENV {"})

# Now start new process
(process (append {newlisp -e "} winfork_ENV {"}))
)

(context 'MAIN)


I haven't used it for a long time so I am not sure if it still works well with the current newLisp version. Funny thing was that the Unix forking examples worked with this program!



As I do not use Windows anymore I cannot verify it's correct functioning, but you probably get the idea.



Regards

Peter