newLisp multi thread in Windows

Machine-specific discussion
Unix, Linux, OS X, OS/2, Windows, ..?
Locked
ale870
Posts: 297
Joined: Mon Nov 26, 2007 8:01 pm
Location: Italy

newLisp multi thread in Windows

Post by 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
Posts: 297
Joined: Mon Nov 26, 2007 8:01 pm
Location: Italy

Post by ale870 »

No multi thread for windows?
--

m35
Posts: 171
Joined: Wed Feb 14, 2007 12:54 pm
Location: Carifornia

Post by 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
Posts: 297
Joined: Mon Nov 26, 2007 8:01 pm
Location: Italy

Post by 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
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Post by 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
Posts: 297
Joined: Mon Nov 26, 2007 8:01 pm
Location: Italy

Post by 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
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Post by 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
Posts: 297
Joined: Mon Nov 26, 2007 8:01 pm
Location: Italy

Post by ale870 »

Ok, I see.
Thank you Lutz!
--

pjot
Posts: 733
Joined: Thu Feb 26, 2004 10:19 pm
Location: The Hague, The Netherlands
Contact:

Post by pjot »

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

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

Code: Select all

(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

Locked