1. RE: Thanks - Threads
- Posted by mistertrik at hotmail.com Jun 18, 2003
- 358 views
Actually.... after pondering possible implementation of threads, I had an idea... what does the list think of this: I thought hey, wouldn't it be nice to call functions and procs and have it return immediately to the calling process, and have the sub proceed independantly, like a thread? Rationalising... a function couldn't possibly work, cause the calling function depends on the value that is returned.... and a thread never returns, it just ends... Well, what about adding a third subroutine? Call it thread or something. It's given certain parameters, and called like a normal procedure... however the parent continues after that, and the thread subroutine continues in parallel... when it finishes, it doesn't go back to the parent, cause the parent's moved on. It just stops. Okay, possible problems: 1. Race Conditions: Well, we would need to have support for semaphores added, at least. signal and wait could act on normal euphoria integers. Other multi-processing things can be discussed..... 2. Existing code: If a thread calls a library function, there are no guaruntees as to what that code would do if it wasn't written with concurrency in mind... So, we need to safeguard the integrity of the library's data. If there are two threads that both call a function or try and change the data in the same library, then whichever one gets there first does so without problems, and the other is suspended until the first thread finishes. That way, no old code will be broken. Of course, some libraries may *want* concurrent access, and will be capable of handling multiple threads accessing it at the same time. Allow that to happen if the library has a "with concurrent" call at the top. 3. Ummm... I don't know... Shoot some holes in my arguments, please. (sorry for double post) ===================================================== .______<-------------------\__ / _____<--------------------__|=== ||_ <-------------------/ \__| Mr Trick >From: Jonas Temple <jtemple at yhti.net> >Reply-To: EUforum at topica.com >To: EUforum <EUforum at topica.com> >Subject: RE: Thanks >Date: Wed, 18 Jun 2003 13:08:04 +0000 > > >That's why I've asked Rob in the past about the possibility of threads >in Eu. I've got some programs that could really benefit from having >threads. > >I'll keep hoping... > >Jonas >Martin Stachon wrote: > > > > > > The problem is that Euphoria is not multi-threaded rather than in OS. > > While we are doing a longer computation (ie not returning from event > > handler in win32lib), we cannot call ?GetNextMessage? (forgot the actual > > > > function name) and Windows are stacking up events in application queue. > > But Windows require the application to handle the event. For example, if > > > > you move a window, WM_MOVE message is issued, but until your application > > > > process the message, the window is not actually moved (the application > > may say it cannot be moved). The OS could possibly have timeouts for > > events, and do default processing after timeout, but you would loose a > > lot of user's actions when high CPU load or application being busy. > > > > If we had at least two threads, win32lib would set up separate thread > > just to handle window events, but the way it is we must call doEvents() > > occasionaly in longer code to handle event queue. > > > > Martin > > > > > >TOPICA - Start your own email discussion group. FREE! > >