I don't get it. Why the read callback should fix the pipe full problem ?
If you set a read callback on your end of the stdout pipe it'd get called when there's data on the pipe, wouldn't it? Then it can just collect the data in (preferably) a String.Buffer object.
No I don't have CVS access.
Shouldn't be a problem to fix (unless possibly if you must have a special deal regarding the copyright). Jhs?
A side issue: Du you think you could shorten the quoted parts of the messages when you respond? I, and probably many other here, like short messages with a minimum of quoting. The mail gateway automatically tacks on the commented message when it's written in LysKOM but unfortunately it doesn't do the reverse for mail messages. So when you respond without cutting away that we essentially get the whole thread in every other message.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-21 14:56: Subject: Re: Contribution
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
I thought it to be useful that it automatically collected stdout. Perhaps it could do that if no stdout argument already is in the mapping?
Sure.
Regardless of whether it's the user or the class itself that does it, the pipe full problem is solved by providing a read callback. The callback stuff only works if there's a backend running anyway.
I don't get it. Why the read callback should fix the pipe full problem ?
As for adding this and your other contributions, do you have cvs access? A good place for the create_process extras would be the Process.Process class, like Nilsson said.
No I don't have CVS access.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 21:32: Subject: Re: Contribution
Hello,
I modified it so that it can be used as a wrapper if you don't provide the callback functions in the mapping. Also it doesn't override anything in the modifiers mapping but you have to provide the fds (see test.pike for an example).
However it has the bug you pointed to but I don't see any solutions. One solution would have been to have something like Thread()->timeout() in Pike (which would be very usefull by the way).
/ David Gourdelier
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Ah, yes, another thing:
o What happens when the process writes a lot of data, so that the stdout pipe gets full? I suspect it will hang until the time out, whereas it could finish successfully had there only been someone to read the data from the pipe.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 00:39: Subject: Contribution
Nice! What is LMTP?
Regarding create_nbprocess:
o Have considered passing the extra arguments through the mapping instead? To me it seems cleaner now when Process.create_process already has left position-based argument passing in favor of a mapping.
o I also note that create_nbprocess bluntly overrides the "stdin" and "stdout" arguments. Preferably it shouldn't, but if it has to then it must be mentioned.
Btw, what's the reason for supplying an stdin pipe at all?
o Ideally I'd like to see this functionality directly in Process.create_process, but I guess it's a bit too much for you to integrate it on the C level. Maybe we could rename the current Process.create_process to something like Process._create_process and then add a Pike level wrapper with this and other goodies?
o You don't need to do remove_call_out of the call out itself inside it; they are one-shot.
o Avoid storing a reference to the object inside itself (i.e. the "process" variable). That makes a circular reference which means more work for the gc. (In 7.5 there's a special hack that avoids counting such references to itself, but it's good practice to try to avoid it anyway since it's not always that hack can discover a cyclic reference.)
/ Martin Stjernholm, Roxen IS
-- -- David Gourdelier
/ Brevbäraren
/ Brevbäraren