One of the long-bemoaned limitations of externals is their inability to send messages into the LC environment asynchronously. I can imagine why this might be very difficult to implement, given that externals often would like to do this from within the context of a different thread, or even in an operating system callback that is called on some unknown thread. I came up against this in writing a MIDI external: output was trivial, but the only way to handle input was to dump it into a FIFO and then poll it from LC in a timer message handler.
The timer message is already one mechanism in LC that allows an asynchronous event to cause a message to be sent: "send <message> to <whom> in <time>". I'm not sure how this is implemented, but the key design point is that the message is prepared in advance, by the LC program, not generated by the arrival of the time, so all the time signal has to do is wake up LC if it is in a waiting state, and set some flag telling LC to dispatch the existing message at the earliest valid point in its message processing loop. A similar mechanism could be implemented for the benefit of externals using semaphores, where the setting of the semaphore would wake up LC if it is in its waiting state. Since a semaphore would only be useful in the context of an external, it is the external that should create the semaphore, typically in its initialization function. LC should provide a function that does this, and that returns a handle of some sort which the external can then return to the LC program in some manner, perhaps by storing it in a LC variable provided as a parameter to the initialization function. And of course, LC would have to define a function that the external could use to set the semaphore. The LC program could then say something like "send <message> to <whom> on <semaphore>". If the semaphore is already set, it would be cleared and the message would be sent immediately; if the semaphore was clear, setting it would wake up LC if it is in its waiting state, and in any case cause the message to be dispatched at the earliest valid time, leaving the semaphore cleared. Typically, the message handler would then call some other function provided by the external to deal with the event. Ideally, the clearing of the semaphore would occur at the point in time when the message is dispatched. The semaphore might actually be implemented with some other OS object, such as a signal in Linux. One might extend the syntax a little further, allowing "send <message> to <whom> on <semaphore> in <time>", to specify a time limit. On entry to the message handler, "the result" could have a value of "true" if the semaphore had been set or "false" if the time limit had expired. So LC would only need to have three functions added to its externals API: a function to create a semaphore, another to delete it (rarely needed), and a function to set the semaphore which can be called from any context. Also, "pendingMessage" would have to add a fifth item, the semaphore handle, to each line. Either the time or the semaphore could be empty. Comments are welcome. -- Ciao, Paul D. DeRocco Paul mailto:pdero...@ix.netcom.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
