On Fri, Apr 26, 2002 at 01:05:13PM -0400, Stephen Adkins wrote: > > We have a private WAN connection to Sabre (the travel reservation system) > and some Sabre interface libraries. We have written the XS interface > so that we can use these Sabre libraries from Perl.
[Sabre requests often take a long time.] > * POE is good if you want to field multiple requests within the same > process. Thus, there can be a lot of interaction between requests > because they share all of the same data. POE Sessions can keep > logically distinct activities from interfering with each other, > but they still all run in the same process. POE will not help you > take advantage of multiple SMP CPU's (until threading becomes more > mainstream), nor will it help if my "handler" needs to make calls to > a library which blocks (my Sabre library) and that doesn't have a > non-blocking interface. Of course, I could always fork a child > process to stick around and do the work (sorry win32 users). A general three-step pattern has emerged for handling blocking network libraries in POE. 1. Have the library send the request (blocking if necessary). 2. Wait asynchronously for the socket to become ready. 3. Receive the response (blocking if necessary). The pattern requires three conditions to be met: 1. The request and response functions are or can be separate. 2. The library exposes a file handle or descriptor to be waited on. 3. The blocking send and receive functions don't take very long once the file is ready to be worked with. In practice, conditions 1 and 2 are toss-ups, although sometimes they can be worked around. Condition 3 is often true, though. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
