Feature request: semaphores for externals

[Paul D. DeRocco]

> From: Mark Wilcox
> 
> Specific to your proposal, if the semaphores are to be 
> created by the external then possibly a semaphore itself is 
> unnecessarily over-specified - unless you were planning to 
> contribute an implementation, in which case the engine 
> contributors board is probably the best place to continue the 
> discussion. At a minimum there needs to be *a* way for 
> externals to trigger, or even better call (with parameters), 
> a script that will be run on the main thread at the next 
> opportunity - what mechanism the external uses to handle the 
> asynchronous processing in the background could well be 
> platform-specific or vary case by case.

What I was trying to suggest was the _minimum_ feature needed to allow
externals to wake up a LC program. Sure, there are lots of other neat things
that could be added, but just having that one simple mechanism would solve
that particular problem, which I'm sure has come up for other people writing
externals.

As to implementation, since I'm just an LC user, it would take me at least
six months of my life to get familiar enough with the guts of LC to do it
myself. At sixty, you can forgive me if I have different priorities for my
twilight years. But I'm hoping there is someone from the company who A)
already knows the LC implementation inside out, B) sees the usefulness of my
suggestion, and C) can dash off an implementation in a week or so.

> If you weren't referring to OS level semaphores and just the 
> abstract concept as something to add to LiveCode for 
> signalling completion of async events then I think it seems a 
> bit of a low-level construct for a language as high-level as 
> LiveCode - if you consider the case where you have multiple 
> async calls outstanding you're basically adding something 
> like an OS scheduler into the event loop. How would this look 
> to callers of the external from within LiveCode and how do 
> you ensure any variable the external call will update is not 
> being accessed in parallel? It's issues like that which make 
> me suggest something like blocks.

I don't think it's that complicated. There's already a mechanism for
maintaining a list of outstanding timer messages, so this would add a
related kind of message to the same list. Whatever underlying mechanism is
needed to implement this "semaphore" would have to wake LC out of its
waiting state (in Windows, MsgWaitForMultipleObjects can be awakened by an
OS semaphore or event object, for instance; in Linux, ppoll can be awakened
by a signal), and then the message dispatch mechanism could check the list
of pending messages to see which one(s) should be launched.

I'm not proposing anything concerning updating a variable from an async
function; that may not even be practical. I'm just proposing a way to let
the external say, "wake up, semaphore x was set", so my LC program can then
call the external function to retrieve whatever input had arrived. Now, I
have to blindly call that function every x milliseconds as a result of a
timer message, which sucks CPU time and imparts a random delay of zero to x
milliseconds.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco at ix.netcom.com