This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Second patch ping


DJ Delorie <dj@redhat.com> writes:

>> Well, now wait a minute, let's think about this.  Suppose we set out
>> to design an interface that didn't have that constraint,
>
> Like http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02407.html ?
>
> Most of the status APIs you listed could easily be added to that
> proposal, as the raw data is hidden anyway.

I continue not to like that proposal on the grounds of its being an
error-handling nightmare.  My preference is for lots of functions that
do one thing each.

>> All the operating systems of interest support 'launch-and-wait'
>> execution of programs:
>
> But not all of them allow you to launch first and then decide if
> you're reading from or writing to the process.

I don't see how this is a problem for the API I proposed.

>> Most of the OSs of interest also support concurrent execution of
>> more than one process, and all the ones that do have pipes.  (Unix,
>> VMS, Windows)
>
> We should assume neither of these, as they are not portable.

And I don't see where my suggested API uses pipes or concurrent
execution as anything other than an optional extra.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]