No subject

       POSIX specifies that a number of system calls (basically, all system  calls
that  may  block,  such  as  read(2),
       write(2),  wait(2),  etc.) and library functions that may call these system
calls (e.g.  fprintf(3)) are cancella­
       tion points.  LinuxThreads is not yet integrated enough with the C library to
implement this, and thus none of the
       C library functions is a cancellation point.

       For  system  calls  at least, there is a workaround. Cancellation requests are
transmitted to the target thread by
       sending it a signal. That signal will interrupt all blocking system calls,
causing them to return immediately with
       the  EINTR  error.  So, checking for cancellation during a read system call,
for instance, can be achieved as fol­
       lows:

              pthread_testcancel();
              retcode = read(fd, buffer, length);
              pthread_testcancel();


>
> If it is feasible to construct an interrupt mechanism for every element
> that might block, then that may be the solution.  But... note that these
> interrupt functions will be run from the top-half's context, not the
> thread's context.  That means that they have to be constructed in a
> thread-safe manner, which for regular sources is a bit of a stretch.  The
> other trick is figuring out which of the elements is currently blocked.
> The iterate() code doesn't keep track of that, and can't anyway without a
> fair amount of overhead shoving a pointer to the next element somewhere
> during every switch.
>
> The advantage of the thread-based signaling approach is that it works
> transparently on all elements, because it simply switches them out.  One
> other potential issue with that is what happens if the I/O comes back from
> a filehandle while the read or write is switched out...?

For best results, any element that may block should be on a Linux pthread.  This
avoids the scenario just described (I/O returns to switched-out cothread).  It
provides a termination mechanism: pthread_cancel().  And it allows other elements
(and the client application) to run while the element is blocked.

To some degree, the autoplugger does this for you by placing thread-bins around
certain elements.


--------------5383C2CC11C28C3C94F3B6E9
Content-Type: text/x-vcard; charset=us-ascii;
 name="brentb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brent Bradburn
Content-Disposition: attachment;
 filename="brentb.vcf"

begin:vcard 
n:Bradburn;Brent
tel;work:(208) 331-2226 x22
x-mozilla-html:FALSE
org:RidgeRun, Inc.
adr:;;;;;;
version:2.1
email;internet:brentb at ridgerun.com
title:Senior Software Developer
x-mozilla-cpt:;-5568
fn:Brent Bradburn
end:vcard

--------------5383C2CC11C28C3C94F3B6E9--