Opposite of yield?

[Isaac To]

Hung> This sounds like event-driven programming to me.

Hung> (1) Usage of threads in principle is optional, but at Python level
Hung> event-driven programming is probably always done in multi-threaded
Hung> environment.

That does not stop somebody who wants something cheaper than threads when he
know that at most one place of his program needs being serviced at each
time.

Hung> (2) Also, at software level, interruptions are always emulated by
Hung> polling (i.e. event loop.) You will have a loop somewhere.

At "software level", most event loops are waited by calling the OS. The OS
can deal with the hardware interrupts caused by devices or timers, or the
signalling caused by other processes. In these ways the OS will not need to
do polling most of the time.

Hung> (3) I won't get into details of the event-handler implementation,
Hung> as it is well-known and you probably already know it or can find
Hung> it easily. But I'd like to mention a simple implementation using
Hung> exception handling. For instance:

Hung> while 1: try: poll_keyboard() poll_mouse() poll_microphone()
Hung> poll_temperature_sensor() except IncomingSignal, e: ... handle
Hung> event ...

Hung> You raise the IncomingSignal event inside the various polling
Hung> routines.

Never do that! You have a lot of ways to avoid holding up the CPU without
doing anything real. No event loop in real systems acts like that, except
for embedded systems that has exactly one program loaded into the memory at
the same time. Instead, use something like select.poll() to wait from more
than one source of input/output, or use a thread as suggested by the parent
thread.

Regards,
Isaac.

 

[Hung Jung Lu]

At "software level", most event loops are waited by calling the OS. The OS
can deal with the hardware interrupts caused by devices or timers, or the
signalling caused by other processes. In these ways the OS will not need to
do polling most of the time.

OSes do polling most of the time: on their idle event loop. Yes,
"idle" is considered an event, too.

Also, events are not restricted to hardware inputs. Users can generate
their own events. Like in the original poster's example: once he
computes a result, he may want to generate an event, and let the
program handle the generated result through an event handler.

Never do that! You have a lot of ways to avoid holding up the CPU without
doing anything real. No event loop in real systems acts like that, except
for embedded systems that has exactly one program loaded into the memory at
the same time. Instead, use something like select.poll() to wait from more
than one source of input/output, or use a thread as suggested by the parent
thread.

Take it easy. It's just a sample code that shows some fun usage of
exception handling in Python. What the original poster asked was
"opposite of yield", and I only wanted to point out that what he
wanted was probably just "event-driven programming", which I was
surprised that no one has mentioned, at all.

My example is just a typical dirty trick of execution flow control in
Python via the exception handling. It's a well-known trick.

I did not mention the details of typical event-driven programming
implementation, because it's known by most programmers. No need for me
to show it here.

regards,

Hung Jung

 

[Jacek Generowicz]

Also reminiscent (a long time ago) someone proposed a COME FROM
statement for FORTRAN to be the inverse of GO TO.

http://c2.com/cgi/wiki?ComeFrom