|
You are quite allright.
why is it so?
In C you just blindly on the address and hope it works.
In .NET the JIT (Just In Time compiler) will compile the method on first call (i.e. transform it from MSIL to machine language), doing so it will make sure all calls are valid, hence it needs to check that all method call are reachable and with the right signature, i.e. it needs to load the DLL and check a few things such as: the dll exist, the version is right, the target methods exist, with the right signature, etc...
Otherwise the method will be deemed invalid and an exception will be thrown
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
I'm playing around with a System.Diagnostics.Process with its IO streams redirected.
Writing to input is working, and I'm able to do non-blocking reads from output by accessing the .BaseStream, but when I try that with the error stream it seems to block no matter what I try.
Has anyone else seen this? Have any ideas about how to accomplish non-blocking reads? Is there a setting I'm not seeing? Should I just not bother with the error stream?
(I don't simply want to do blocking reads on a different thread; I'd likely have to Abort the thread.  )
modified on Wednesday, March 31, 2010 2:22 PM
|
|
|
|
|
Hi PIEBALD,
I typically use two extra (background) threads to read the output and the error streams; it works fine for me on all NT-like versions (there always were problems on Win98/Me). The alternative would be to use the OutputDataReceived and ErrorDataReceived events (available since .NET 2.0), which get handled on a ThreadPool thread.
FWIW: one should not abort a thread; it is troublesome as the outcome is unpredictable.
|
|
|
|
|
Luc Pattyn wrote: one should not abort a thread
Which is part of why I don't want to use one for this; I don't expect any data coming from the error stream anyway.
Personally I have nothing against aborting a thread in such a case.
Luc Pattyn wrote: OutputDataReceived and ErrorDataReceived
But "the ErrorDataReceived event signals each time the process writes a line to the redirected StandardError stream" and I don't want to wait for complete lines, there may not be any newlines in the output -- I want non-blocking IO; if there's no data, just tell me there's no data!
And I expect it's executing on a thread which would have to be aborted in the background, so nothing is gained.
But the real mystery is why the two streams appear to behave differently.
|
|
|
|
|
If you don't like the way the events operate, you'll have to use your own threads and perform some kind of Read() calls. As I said, that is what I do.
BTW: I'm not sure I believe the documentation when it says the events fire on every output/error line, there probably is some buffering going on in the child process, hiding the individual WriteLine operations. I guess it only shows if sufficient data is available (some threshold exceeded) or maybe some data + some timeout.
PIEBALDconsult wrote: But the real mystery is why the two streams appear to behave differently.
I don't remember that. Do they do that consistently? which app(s)?
|
|
|
|
|
Luc Pattyn wrote: Do they do that consistently?
They seem to. Output will return 0 when there's no data, but error will block indefinitely. It could, of course, be due to output having data some times and error never does. I'd have to write a little utility that will write to error to test that out.
Luc Pattyn wrote: which app(s)?
So far, I've been testing with a utility of mine, I'll try it with FTP or something.
WTF!  FTP and telnet don't seem to be prompting when run in a Process!
NSLOOKUP prompts, but I still hang when trying to read the error stream.
modified on Tuesday, March 30, 2010 7:37 PM
|
|
|
|
|
I wrote a little console app that writes its output to error rather than output and it worked fine.
|
|
|
|
|
I just experimented a bit with process stream redirections and created this article[^]. It all works as I expected.
|
|
|
|
|
But what if the slave uses Write rather than WriteLine?
I suppose I could download your code and try that myself...
|
|
|
|
|
the way standard output & error work in .NET is optimized for line-oriented processing; I am guessing the slave process emits output/error data through some buffers, these get transferred occasionally (independent of newlines), the master gets hold of those buffers and searches for line terminators; for each one found it triggers a DataReceived event. AFAIK the underlying i.e. Win32 mechanism is not line-oriented. You not using NewLine means DataReceived events are useless for you, so you need either threads or async operations and collect and parse incoming data yourself.
the one point I have been making is output and error are handled basically the same (although I have a suspicion there may be more buffering at the sender side for stdout than there is for stderr).
|
|
|
|
|
Luc Pattyn wrote: DataReceived events are useless for you
Right. I just tested it and saw what I expected.
Luc Pattyn wrote: underlying i.e. Win32 mechanism is not line-oriented
Right, and using the .BaseStream almost works -- e.g. it works for Output, but not for Error. I wonder whether or not I can get lower...
The only thing I can think of that would cause the difference in behaviour is different backing stores, but why would the two streams have different backing stores? 
P.S. I added commands:
"o" -- Out.Write
"e" -- Error.Write
"a" -- I made autowait an int; "a" decrements it, "A" increments it
|
|
|
|
|
|
I was just poking around in the non-public fields...
Out is a System.IO.__ConsoleStream
Error is a System.IO.NullStream 
|
|
|
|
|
What is the difference between "Excel 2007 Add-in" project and "Excel 2007 Workbook" project ?
|
|
|
|
|
The Add-in allows you to write a plugin for Excel, and it will be loaded when Excel starts. The first is an application-level addin, the second a document-level addin.
Start here[^] 
I are Troll 
|
|
|
|
|
|
Hi,
I have a database (access) that contains a table GALLERY.
Now i need while uploading a file to insert the path in this way to the db
"~/photo/XXX.JPG"
What i get right now is only the file's name.
This is what i used for saving the path
FileUpload1.SaveAs(Server.MapPath("~/photo/" + FileUpload1.FileName));
I've tried it with and without the Server.MapPath.
The resault without the server.mappath was "The SaveAs method is configured to require a rooted path..bla bla bla"
With the Server.MapPath it works but not the way i need it. as i said it inserts only the file's name to the DB.
Can anyone please help me with that.
Thank you,
Basil.
|
|
|
|
|
Do not post to multiple forum 
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
What database are you using. If your database generate the problem on saving the file path. You can Encrypt the path and Then save to it.
If you can think then I Can.
|
|
|
|
|
im using an ACCESS DB, what do you mean by encrypting the path
|
|
|
|
|
If you are using Access DB then replace the \ to \\ and save it.
the second method is to save in database is encrypt the path.
If you can think then I Can.
|
|
|
|
|
thanks for your answer, please tell me what do you mean by encrypting the path, you mean to encrypt the path string before inserting to the DB, how would i do that ?
|
|
|
|
|
If your Path Name have a Special Character that database is not support. Then you can use to convert this path to a another string by using diffrent encryption method.
If you can think then I Can.
|
|
|
|
|
i need you to tell me HOW to encrypt it
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
