- Mpi3-subsetting - mailman3.cels.anl.gov

Re: [Mpi3-subsetting] MPI3: Proposal to remove PMPI-Requirement
by unknown＠example.com 05 Mar '08

05 Mar '08

Hi, Thanks. Interesting. I wonder in what relation this will stand with the ABI activity. Best regards. Alexander -----Original Message----- From: mpi3-subsetting-bounces_at_[hidden] [mailto:mpi3-subsetting-bounces_at_[hidden]] On Behalf Of Rainer Keller Sent: Wednesday, March 05, 2008 9:15 PM To: MPI3-Subsetting_at_[hidden] Subject: [Mpi3-subsetting] MPI3: Proposal to remove PMPI-Requirement Dear Alexander, dear all, at the previous Chicago meeting, some of us (Rich Graham, Jeff Squyres, Hubert Ritzdorf) have been discussing about the MPI-Standard's requirement to provide PMPI-functions for each MPI-Call into the library (except MPI_Wtime, MPI_Wtick). This is in my eyes a limitation: there could be some gains for the common case of large-scale applications: - Not using PMPI-based tools (dynamically loaded in) - Not using MPI_PROC_NULL - Not using MPI_STATUS_IGNORE So, if this proposal would fit Your definition of MPI3-Subsets, I would like to discuss the removal of the PMPI-function requirement, allowing inlining of MPI-functions and, based on that, pre-processor hints, e.g. MPI_HINT_NO_THREADS or MPI_HINT_NO_ANY_SOURCE, so the compiler might be able to eliminate several if-statements in the fast-path, allowing inlining, allowing dead code elimination. (of course, there is a whole lot of further issues involved, here -- please see the last section in the document). I have included some timings with NetPipe on Open MPI using these hints (further information section 4 -- Ompi Patch availble upon request, as its work in progress). Please take the timings with a grain of salt. I would like to get better figures on a more well-defined cluster environment. Any comments would be welcome. With best regards, Rainer -- ---------------------------------------------------------------- Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller HLRS Tel: ++49 (0)711-685 6 5858 Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832 70550 Stuttgart email: keller_at_[hidden] Germany AIM/Skype:rusraink --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

MPI3: Proposal to remove PMPI-Requirement
by unknown＠example.com 05 Mar '08

05 Mar '08

Dear Alexander, dear all, at the previous Chicago meeting, some of us (Rich Graham, Jeff Squyres, Hubert Ritzdorf) have been discussing about the MPI-Standard's requirement to provide PMPI-functions for each MPI-Call into the library (except MPI_Wtime, MPI_Wtick). This is in my eyes a limitation: there could be some gains for the common case of large-scale applications: - Not using PMPI-based tools (dynamically loaded in) - Not using MPI_PROC_NULL - Not using MPI_STATUS_IGNORE So, if this proposal would fit Your definition of MPI3-Subsets, I would like to discuss the removal of the PMPI-function requirement, allowing inlining of MPI-functions and, based on that, pre-processor hints, e.g. MPI_HINT_NO_THREADS or MPI_HINT_NO_ANY_SOURCE, so the compiler might be able to eliminate several if-statements in the fast-path, allowing inlining, allowing dead code elimination. (of course, there is a whole lot of further issues involved, here -- please see the last section in the document). I have included some timings with NetPipe on Open MPI using these hints (further information section 4 -- Ompi Patch availble upon request, as its work in progress). Please take the timings with a grain of salt. I would like to get better figures on a more well-defined cluster environment. Any comments would be welcome. With best regards, Rainer -- ---------------------------------------------------------------- Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller HLRS Tel: ++49 (0)711-685 6 5858 Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832 70550 Stuttgart email: keller_at_[hidden] Germany AIM/Skype:rusraink *

1 0

Re: [Mpi3-subsetting] mpi3-subsetting Digest, Vol 2, Issue 3
by unknown＠example.com 05 Mar '08

05 Mar '08

> Also, lots of people seem to like the idea of getting rid of MPI_ANY_SOURCE > in a subset. I am one of these people. MPI_ANY_SOURCE is a problem. The > difficulty is that the master in a master worker algorithm is likely to > find MPI_ANY_SOURCE and MPI_PROBE useful. This issue captures a (the?) key decision that this group must make imo. Is the goal of the sub-setting to provide a performance boost, or to address the "mpi is too big" concern? In some sense the concerns overlap, but here is a big example of where they often don't. Many of the applications I've worked with use it in setting up communication (esp. in amr codes). And many of these people asked for an mpi-subset. Interesting to note that for many of these codes, actual performance of the send/recv is _not_ an issue - the work associated with preparing and managing messages for those sorts of codes, as well as the work imbalances, overwhelm the performance issues. (But note these code teams may _say_ mpi performance is an issue, but a complete view of their communication requirements does not support that claim.) However, they also require MPI_ALL_REDUCE, and at the peta-scale, so performance there is critical. MPI_ANY_SOURCE is found in many libraries I use, but library developers seem to make significant use of mpi functionality, without complaint. All this said, admittedly counter-claims and examples may be produced. However, as Dick stated for the Master/worker model, a large segment of users "require" MPI_ANY_SOURCE" somewhere in their code. I'm not saying a decision needs to be reached quickly, but I do believe we should keep this issue clearly in view in order to keep the discussions on-track. Richard -- Richard Barrett Future Technologies Group, Computer Science and Mathematics Division, and Scientific Computing Group, National Center for Computational Science Oak Ridge National Laboratory http://ft.ornl.gov/~rbarrett

1 0

Subsetting slides
by unknown＠example.com 05 Mar '08

05 Mar '08

One argument for subsetting is that MPI is somehow not well suited to massive master-worker applications. It does seem reasonable to me that pure master-worker applications have little use for many of MPI's features. Most communication may be point to point because workers are not expected to cooperate or communicate among themselves. Groups, topologies, new communicators, MPI-IO etc are not very useful. In the simple case, the master hands each worker a piece of work to do and the worker runs on its own until the work is done. As a worker finishes, it sends an answer to the master and waits to be handed another piece of work. Some pieces of work are brief and some are not so workers are not synched with each other and the master does not know who will have an answer next. My impression is that the biggest problem with MPI for this model is that with one master and many workers, it is not hard to make an application that can survive the loss of one or more workers. The master just hands out the lost work assignment again. MPI is not an ideal fit because the loss of one member of MPI_COMM_WORLD will probably bring down the job. A simple subset will not resolve this. An Fault Tolerant subset could be considered if this is an important rationale for a subset. Also, lots of people seem to like the idea of getting rid of MPI_ANY_SOURCE in a subset. I am one of these people. MPI_ANY_SOURCE is a problem. The difficulty is that the master in a master worker algorithm is likely to find MPI_ANY_SOURCE and MPI_PROBE useful. Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 *

1 0

Subsetting slides for F2F meeting: please comment by EOD March 6, 2008
by unknown＠example.com 05 Mar '08

05 Mar '08

Hi everybody, Here come the promised draft slides for the subsetting presentation at the MPI Forum. I put this into our corporate template, I hope everybody is OK with this. Your comments will be most appreciated. I would like to finalize the slides on Friday, so please send your feedback by EOD your time on Thursday, March 6, 2008. Sorry for the message size. I cannot upload this file to the Wiki due to file size limitation there. I work this with Rich in background. Best regards. Alexander -- Dr Alexander Supalov Intel GmbH Hermuelheimer Strasse 8a 50321 Bruehl, Germany Phone: +49 2232 209034 Mobile: +49 173 511 8735 Fax: +49 2232 209029 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. *

1 0

Re: [Mpi3-subsetting] agenda for subsetting kickoff telecon ww09
by unknown＠example.com 29 Feb '08

29 Feb '08

One other issue is that we'd have to make [at least some of] the MPI_Info_* functions be able to be called before MPI_INIT. On Feb 29, 2008, at 3:54 PM, Supalov, Alexander wrote: > Hi, > > Thanks. I was thinking privately about MPI_Init_subsets or so that > would > use an Info object, too. I bet a comparable idea - or at least > desire to > keep the number of subset related calls under strict control - was > aired > at the telecon by someone, but we didn't go into much detail then. > > One reservation I have about Info objects is that they are so flexible > as to be dangerous. They promoting lots of optional, loosely > controlled > features that can effectively blur the interface definition. On the > other hand, I don't see any viable alternative to that, at least if > the > number of subsets is going to be substantial and ever growing. > > Of course, it's a little too early to fix any implementation details > I'm > afraid. Anyway, let's keep this idea in mind while we're settling the > scope. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi3-subsetting-bounces_at_[hidden] > [mailto:mpi3-subsetting-bounces_at_[hidden]] On Behalf Of Jeff > Squyres > Sent: Friday, February 29, 2008 9:29 PM > To: mpi3-subsetting_at_[hidden] > Subject: Re: [Mpi3-subsetting] agenda for subsetting kickoff telecon > ww09 > > On Feb 28, 2008, at 11:29 PM, Supalov, Alexander wrote: > >> - Communicator & group management: better memory footprint. > > Take this point to an extreme - it may be possible to say "this app > only uses MPI_COMM_WORLD". In this case, you can remove the > communicator field from network packets for a small gain in latency, > or perhaps reduce it from 4 to 2 bytes or 1 byte (e.g., if an app says > "I'll only use 4 communicators"). > >> - Message tagging: better support for stable dataflow exchanges, >> smaller >> packets. > > Two points here: > > - allow app to eliminate MPI_ANY_TAG > - just like with communicators, allow the app to say "I'll only use N > tags", where N can save you space in network packets (e.g., if N==1, > no need for tag on the wire; if N == 2, then you only need 1 byte for > the tag, etc.). > >> - Non-blocking communication: easier ordering, simplified request >> handling. > > > If there is no non-blocking communication, enormous chunks of the > progression engine can be optimized in terms of memory (i.e., remove > lots of now-unnecessary code) and probably a little speed. > > On the teleconf (sorry I missed it), was there discussion of how to > specify these hints? Perhaps a new function: MPI_INIT_INFO (pass an > MPI_Info handle to MPI_INIT)? Or is it something that needs to be > specified at compile/link time? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > Mpi3-subsetting mailing list > Mpi3-subsetting_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > Mpi3-subsetting mailing list > Mpi3-subsetting_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi3-subsetting] agenda for subsetting kickoff telecon ww09
by unknown＠example.com 29 Feb '08

29 Feb '08

Hi, Thanks. I was thinking privately about MPI_Init_subsets or so that would use an Info object, too. I bet a comparable idea - or at least desire to keep the number of subset related calls under strict control - was aired at the telecon by someone, but we didn't go into much detail then. One reservation I have about Info objects is that they are so flexible as to be dangerous. They promoting lots of optional, loosely controlled features that can effectively blur the interface definition. On the other hand, I don't see any viable alternative to that, at least if the number of subsets is going to be substantial and ever growing. Of course, it's a little too early to fix any implementation details I'm afraid. Anyway, let's keep this idea in mind while we're settling the scope. Best regards. Alexander -----Original Message----- From: mpi3-subsetting-bounces_at_[hidden] [mailto:mpi3-subsetting-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, February 29, 2008 9:29 PM To: mpi3-subsetting_at_[hidden] Subject: Re: [Mpi3-subsetting] agenda for subsetting kickoff telecon ww09 On Feb 28, 2008, at 11:29 PM, Supalov, Alexander wrote: > - Communicator & group management: better memory footprint. Take this point to an extreme - it may be possible to say "this app only uses MPI_COMM_WORLD". In this case, you can remove the communicator field from network packets for a small gain in latency, or perhaps reduce it from 4 to 2 bytes or 1 byte (e.g., if an app says "I'll only use 4 communicators"). > - Message tagging: better support for stable dataflow exchanges, > smaller > packets. Two points here: - allow app to eliminate MPI_ANY_TAG - just like with communicators, allow the app to say "I'll only use N tags", where N can save you space in network packets (e.g., if N==1, no need for tag on the wire; if N == 2, then you only need 1 byte for the tag, etc.). > - Non-blocking communication: easier ordering, simplified request > handling. If there is no non-blocking communication, enormous chunks of the progression engine can be optimized in terms of memory (i.e., remove lots of now-unnecessary code) and probably a little speed. On the teleconf (sorry I missed it), was there discussion of how to specify these hints? Perhaps a new function: MPI_INIT_INFO (pass an MPI_Info handle to MPI_INIT)? Or is it something that needs to be specified at compile/link time? -- Jeff Squyres Cisco Systems _______________________________________________ Mpi3-subsetting mailing list Mpi3-subsetting_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [Mpi3-subsetting] agenda for subsetting kickoff telecon ww09
by unknown＠example.com 29 Feb '08

29 Feb '08

On Feb 28, 2008, at 11:29 PM, Supalov, Alexander wrote: > - Communicator & group management: better memory footprint. Take this point to an extreme - it may be possible to say "this app only uses MPI_COMM_WORLD". In this case, you can remove the communicator field from network packets for a small gain in latency, or perhaps reduce it from 4 to 2 bytes or 1 byte (e.g., if an app says "I'll only use 4 communicators"). > - Message tagging: better support for stable dataflow exchanges, > smaller > packets. Two points here: - allow app to eliminate MPI_ANY_TAG - just like with communicators, allow the app to say "I'll only use N tags", where N can save you space in network packets (e.g., if N==1, no need for tag on the wire; if N == 2, then you only need 1 byte for the tag, etc.). > - Non-blocking communication: easier ordering, simplified request > handling. If there is no non-blocking communication, enormous chunks of the progression engine can be optimized in terms of memory (i.e., remove lots of now-unnecessary code) and probably a little speed. On the teleconf (sorry I missed it), was there discussion of how to specify these hints? Perhaps a new function: MPI_INIT_INFO (pass an MPI_Info handle to MPI_INIT)? Or is it something that needs to be specified at compile/link time? -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi3-subsetting] MPI_ANY_SOURCE
by unknown＠example.com 29 Feb '08

29 Feb '08

I heard Myricom MX would not allow recv cancellation. This needs to be checked. -----Original Message----- From: mpi3-subsetting-bounces_at_[hidden] [mailto:mpi3-subsetting-bounces_at_[hidden]] On Behalf Of Richard Graham Sent: Friday, February 29, 2008 5:59 PM To: mpi3-subsetting_at_[hidden] Subject: Re: [Mpi3-subsetting] MPI_ANY_SOURCE On 2/29/08 11:30 AM, "Supalov, Alexander" <alexander.supalov_at_[hidden]> wrote: > I see. Sorry for explaining the obvious. I guess the progress engine may > take a hit every time there are either an MPI_ANY_SOURCE Recv or (thanks > to Rich) multiple paths between the processes. Hence, all transfers are > potentially affected. With any_source the message can come from anyone, so the cost really depends on the mpi's queuing strategy, so the actual cost is very implementation specific. What ever the cost is, there are more potential sources, so at 100k there are 100k potential sources. The queuing could always have the unexpected messages cached in a single queue, but then all matching would be more expensive, vs. more of a hierarchical queue structure .... For expected messages there can also be an increase in matching costs, but again this is implementation specific. The other cost is that matching really has to be done at the destination - just a practical need - try to cancel 100k posted receives, after one match has been made, and make sure that only one proc has done the match. > > Cancellation is a sticky matter. Some fabrics won't let you do this, so > a cancel will always misfire. Is this the case on the receive side ? The cancellation that Richard is mentioning is a receive side cancellation. I don't remember a network with this limitation, but I could very well be wrong on this one - I suppose it can also depend on how you do the matching. Rich > > -----Original Message----- > From: mpi3-subsetting-bounces_at_[hidden] > [mailto:mpi3-subsetting-bounces_at_[hidden]] On Behalf Of > Richard Barrett > Sent: Friday, February 29, 2008 5:02 PM > To: mpi3-subsetting_at_[hidden] > Subject: [Mpi3-subsetting] MPI_ANY_SOURCE > > > >>> Now, to one of your questions. An MPI_ANY_SOURCE > > Although I appreciate the discussion, my intent (uh-oh!) in bring this > up to > let you know I "accept" the problem, yet ask for the capability anyway, > but > in a manner that keeps it from presenting problems everywhere. Or maybe > I'm > under-estimating what I was once told: the use of MPI_ANY_SOURCE > anywhere > means it is a problem everywhere, ie in _every_ function involved in > transmitting data? > > If that is the case, but I still _really_ wanted to use -lmpi_subset, I > could do this: suppose a pe knows it will receive data from m pes. It > could > post numpe non-blocking receives, complete m, discover who they're from, > then cancel the rest. Now I'm thinking I've created a bigger problem: > when > running acros numpes=100k cores, but m is say 10. True? > > Barring some sort of workaround, excluding codes that "need" > MPI_ANY_SOURCE > seems to meaningfully reduce the number of codes that could use > -lmpi_subset. > >> 3. I (basically) understand the adverse performance effects of > allowing > promiscuous receives (MPI_ANY_SOURCE). However, this is a powerful > capability > for many codes, and used only in moderation, eg for setting up > communication > requirements (such as communication partners in unstructured, > semi-structured, > and dynamic mesh computations). In this case the sender knows its > partner, but > the receiver does not. A reduction(sum) is used to let each process know > the > number of communication partners from which it will receive data, the > process > posts that many promiscuous receives, which when satisfied lets it from > then on > specify the sender. So would it be possible to include this capability > in a > separate function, say the blocking send/recv, but not allow it in the > non-blocking version? > > Richard _______________________________________________ Mpi3-subsetting mailing list Mpi3-subsetting_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [Mpi3-subsetting] MPI_ANY_SOURCE
by unknown＠example.com 29 Feb '08

29 Feb '08

On 2/29/08 11:30 AM, "Supalov, Alexander" <alexander.supalov_at_[hidden]> wrote: > I see. Sorry for explaining the obvious. I guess the progress engine may > take a hit every time there are either an MPI_ANY_SOURCE Recv or (thanks > to Rich) multiple paths between the processes. Hence, all transfers are > potentially affected. With any_source the message can come from anyone, so the cost really depends on the mpi's queuing strategy, so the actual cost is very implementation specific. What ever the cost is, there are more potential sources, so at 100k there are 100k potential sources. The queuing could always have the unexpected messages cached in a single queue, but then all matching would be more expensive, vs. more of a hierarchical queue structure .... For expected messages there can also be an increase in matching costs, but again this is implementation specific. The other cost is that matching really has to be done at the destination - just a practical need - try to cancel 100k posted receives, after one match has been made, and make sure that only one proc has done the match. > > Cancellation is a sticky matter. Some fabrics won't let you do this, so > a cancel will always misfire. Is this the case on the receive side ? The cancellation that Richard is mentioning is a receive side cancellation. I don't remember a network with this limitation, but I could very well be wrong on this one - I suppose it can also depend on how you do the matching. Rich > > -----Original Message----- > From: mpi3-subsetting-bounces_at_[hidden] > [mailto:mpi3-subsetting-bounces_at_[hidden]] On Behalf Of > Richard Barrett > Sent: Friday, February 29, 2008 5:02 PM > To: mpi3-subsetting_at_[hidden] > Subject: [Mpi3-subsetting] MPI_ANY_SOURCE > > > >>> Now, to one of your questions. An MPI_ANY_SOURCE > > Although I appreciate the discussion, my intent (uh-oh!) in bring this > up to > let you know I "accept" the problem, yet ask for the capability anyway, > but > in a manner that keeps it from presenting problems everywhere. Or maybe > I'm > under-estimating what I was once told: the use of MPI_ANY_SOURCE > anywhere > means it is a problem everywhere, ie in _every_ function involved in > transmitting data? > > If that is the case, but I still _really_ wanted to use -lmpi_subset, I > could do this: suppose a pe knows it will receive data from m pes. It > could > post numpe non-blocking receives, complete m, discover who they're from, > then cancel the rest. Now I'm thinking I've created a bigger problem: > when > running acros numpes=100k cores, but m is say 10. True? > > Barring some sort of workaround, excluding codes that "need" > MPI_ANY_SOURCE > seems to meaningfully reduce the number of codes that could use > -lmpi_subset. > >> 3. I (basically) understand the adverse performance effects of > allowing > promiscuous receives (MPI_ANY_SOURCE). However, this is a powerful > capability > for many codes, and used only in moderation, eg for setting up > communication > requirements (such as communication partners in unstructured, > semi-structured, > and dynamic mesh computations). In this case the sender knows its > partner, but > the receiver does not. A reduction(sum) is used to let each process know > the > number of communication partners from which it will receive data, the > process > posts that many promiscuous receives, which when satisfied lets it from > then on > specify the sender. So would it be possible to include this capability > in a > separate function, say the blocking send/recv, but not allow it in the > non-blocking version? > > Richard

1 0