Difference between revisions of "User:Jamesboston/nsIProcess/meeting-110508"

From CDOT Wiki
Jump to: navigation, search
(New page: Date : Nov 5, 2008<br /> Topic : API design, callbacks, implementing inter-process communication<br /> People: James Boston (jboston), Mark Finkle (mfinkle)<br /> <pre> 15:33 < jboston> ...)
(No difference)

Revision as of 15:23, 6 November 2008

Date  : Nov 5, 2008
Topic : API design, callbacks, implementing inter-process communication
People: James Boston (jboston), Mark Finkle (mfinkle)

15:33 < jboston> mfinkle: http://pastebin.mozilla.org/570000
15:33 < jboston> Wrestling with callbacks.
15:33 < jboston> I'm not sure I can do what I'm trying to do.
15:34 < jboston> I want to get i/o one line at a time.
15:35 < mfinkle> ok, first - how will the i/o actually get put into the callback?
15:35 < mfinkle> I wouldn't worry too much about the callee "getting" the i/o
15:35 < mfinkle> (yet)
15:36 < jboston> Well, I guess all the i/o stuff happens in cpp somewhere in it's own thread.
15:39 < jboston> See, when the process object is created, I'm assuming that it is handling i/o in the background.
15:40 < jboston> Have I got my callbacks backwards? For instance, stdout.getline() would be implemented in cpp.
15:41 < jboston> This is different from having the cpp call the js code when it's ready with something.
15:41 < jboston> Am I talking crazy talk.
15:43 < mfinkle> well, assuming the processes will write to stdout, how will you capture that in c++?
15:43 < mfinkle> some NSPR buffer?
15:44 < jboston> Maybe. I haven't figured that out.
15:44 < jboston> I thought it would go into a queue where I can could retreive one line at a time as needed.
15:45 < mfinkle> jboston: what queue? do you provide one?
15:45 < jboston> I would.
15:46 < mfinkle> ok, so this queue has a datatype? char*, some buffer?
15:46 < jboston> maybe i need stdin = process.getStdIn(); var line = stdin.getline();
15:46 < jboston> yes.
15:46 < mfinkle> we need to know this so you can make a JS compatible wrapper for the callbacks
15:46 < mfinkle> ID for this queue is needed too
15:47 < mfinkle> do you really need this "line by line" feature? why not just a stream buffer
15:47 < mfinkle> let the caller deal with it
15:48 < jboston> Ok. I think I'm confused somewhere about how this works. I'll have a callback to js code that
                 handles a stream buffer?
15:49 < mfinkle> jboston: first things first
15:49 < mfinkle> does this work at all in NSPR?
15:49 < mfinkle> or do you need to add machinery?
15:50 < jboston> I don't know.
15:50 < mfinkle> then let's not worry about the JS part
15:50 < jboston> Ok.
15:51 < mfinkle> but keep this in mind: callbacks are like events, you could fire it for each line
15:51 < jboston> Ah!
15:51 < mfinkle> buffers would be passed in and not used until the process ends
15:51 < mfinkle> then they could be read in part or in full
15:51 < jboston> Hrm. But what about processes that I expect to run as long as the browser is running.
15:51 < mfinkle> if you think the output could be large, callbacks could be painfully slow
15:52 < jboston> i guess that's the problem i was getting at in my own peculiar way.
15:53 < mfinkle> jboston: consider this - until you know the real implementation details, you might not be able to fire a callback until the process finishes
15:54 < jboston> ok. i've been trying to approch it from high level to low level, but i'm getting lost. i'll take
                 your advice and dive back into the cpp.
15:55 < jboston> You're help is very much appreciated here. You're blog post on callbacks was very informative.