OpenEuphoria

Re: Threads [Was: Re: 64 bit euphoria]

• Posted by codepilot Gmail Account <codepilot at gmail.com> Apr 27, 2005
• 530 views

On 4/27/05, Pete Lomax <petelomax at blueyonder.co.uk> wrote:
>
> On Wed, 27 Apr 2005 07:17:39 +1000, Patrick Barnes <mrtrick at gmail.com>
> wrote:
>
> >
> >On 4/26/05, Pete Lomax <petelomax at blueyonder.co.uk> wrote:
> >> OK: GENERAL QUESTION TO ALL:
> >>
> >> If there was something you wanted threads for, what would it look like
> >> in your ideal snippet of Euphoria code?
> >
> >The thing that a true threaded model can offer that a simulated model
> >can NEVER offer is preemptive multitasking (as opposed to cooperative)
> Isn't that a function of the OS rather than an individual application?
> >
> >Ideally, a 'thread' would be similar to a procedure or function
> >declaration.
> OK, I would argue strongly against a function, which implies the
> inititiator/initiating thread has to wait for a result, which negates
> any parallelism. I can also imagine there is a routine which you might
> want to make a thread in some cases, but also perform immediately, so
> I'd stick with procedure.
I agree there, a function implies something gets returned.
>
> I would also, from your post, suggest that something like
> }}}
<eucode>
> procedure onButtonClick(id, event, params)
>         fork(routine_id("long_processing_job"),{})
> end procedure
> </eucode>
{{{

> might be much more descriptive of what was actually happening.
>
> > A few other things like semaphore (wait and signal) and
> >mutex support would be nice too.
> And how you might they look? lockSemaphore(..)/releaseSemaphore(..)?
> Assume that RC creates Euphoria/include/threads.e which provides the
> basic wrappers around machine_func/proc, c_func/proc, or similar.
>
> <snip>
> >For instance, here is a function(originally) called
> >long_processing_job. While iterative, there's no easy way to insert
> >doEvents(0) calls, as at one level it's called too often, and at the
> >next level it may not be called enough.
> Can you explain what you mean there? In what cases would it be called
> too often, and why, and in what cases would it not be called enough,
> and why?
Well mabey

for doc = 1 to length(documents_to_parse) do
--doEvents won't get called but once each document
for character = 1 to length(documents_to_parse[doc]) do
--doEvents would get called way too offten, for each character,
majorly slowing down the parsing
end for
end for

>
> >
> >A more mature thread implementation might support one thread
> >triggering a windows API event in the first, rather than being
> >polling.
> Well, I would hope that only one thread owns a control, and it is that
> thread which handles windows messages, so I don't understand the
> sentiment there one bit. The message queue is thread agnostic.
Well, I think you can send windows messages to any window you want,
for signaling things. But the windows messaging API is either polling,
or blocking, so using the messaging to avoid polling is not really
possible, unless you like the blocking better.
Dan
>
> Regards,
> Pete
>
>
>
>
>