Is this safe
-
I need to communicate with fiscal printer via third party software (Don't ask me way). I'm sending command file in one folder and receive answer file in another folder. My print method need to return number of fiscal invoice which is generated by printer and can be found in answer file. So my method look like this
public int PrintInvoice()
{
//Do some code of sending command file//Wait until answer file received while(!\_answerFileReceived){} //Process answer file and return Invoice number
}
Also I have FileSystemWatcher which monitor answer directory (file creation) with code
fswWatcher_FileCreated(object sender, FileSystemEventArgs e)
{
_answerFileReceived = true;
}My question is "Is this safe" and can I have exceptions, or do you have any suggestion of another approach to above problem. Thank you.
-
I need to communicate with fiscal printer via third party software (Don't ask me way). I'm sending command file in one folder and receive answer file in another folder. My print method need to return number of fiscal invoice which is generated by printer and can be found in answer file. So my method look like this
public int PrintInvoice()
{
//Do some code of sending command file//Wait until answer file received while(!\_answerFileReceived){} //Process answer file and return Invoice number
}
Also I have FileSystemWatcher which monitor answer directory (file creation) with code
fswWatcher_FileCreated(object sender, FileSystemEventArgs e)
{
_answerFileReceived = true;
}My question is "Is this safe" and can I have exceptions, or do you have any suggestion of another approach to above problem. Thank you.
Why not using event instead of infinite loop ? :doh: ie:
fswWatcher_FileCreated(object sender, FileSystemEventArgs e)
{
MyInvoiceClass = newe MyInvoiceClass();
int invoiceID = MyInvoiceClass. PrintInvoice();// Your stuff here
}
-
Why not using event instead of infinite loop ? :doh: ie:
fswWatcher_FileCreated(object sender, FileSystemEventArgs e)
{
MyInvoiceClass = newe MyInvoiceClass();
int invoiceID = MyInvoiceClass. PrintInvoice();// Your stuff here
}
-
I agree with you, but my Print method is inside class and must return Invoice number. Class name is FiscalPrinter and it has method PrintInvoice. So I call
FiscalPrinter printer = new FiscalPrinter()
//Assing some properties
//Print invoice and get invoice number
int InvoiceNumber = printer.PrintInvoice();
Thats why I'm using infinite loop (it will be extended to wait some amount time so it won't be infinite), and I'm not sure is this approach safe. Thank you for your answers.
-
I agree with you, but my Print method is inside class and must return Invoice number. Class name is FiscalPrinter and it has method PrintInvoice. So I call
FiscalPrinter printer = new FiscalPrinter()
//Assing some properties
//Print invoice and get invoice number
int InvoiceNumber = printer.PrintInvoice();
Thats why I'm using infinite loop (it will be extended to wait some amount time so it won't be infinite), and I'm not sure is this approach safe. Thank you for your answers.
Well there is a problem with that, while you are looping/waiting the event loop can not process the event raised by the file system watcher. Or is it on a different thread? In that case, you should definitely use a real synchronization primitive instead of busy-waiting.
-
Well there is a problem with that, while you are looping/waiting the event loop can not process the event raised by the file system watcher. Or is it on a different thread? In that case, you should definitely use a real synchronization primitive instead of busy-waiting.
Asynchronous events tend to get handled on
TrheadPool
threads, see here[^]. I didn't test specifically forFileSystemWatcher
, however I expect them to behave similarly. So yes busy loops are bad and inter-thread synchronization is recommended. :)Luc Pattyn [My Articles] Nil Volentibus Arduum iSad
-
Asynchronous events tend to get handled on
TrheadPool
threads, see here[^]. I didn't test specifically forFileSystemWatcher
, however I expect them to behave similarly. So yes busy loops are bad and inter-thread synchronization is recommended. :)Luc Pattyn [My Articles] Nil Volentibus Arduum iSad
-
Well I like to be sure so I looked it up; the example on msdn:filesystemwatcher[^] shows that FSW events happen on a different threat
Well, it doesn't show it, what it does is proof or disproof depending on whatever the behavior is when you actually run that code. Will it hang waiting for exit? or will it ever report something? They don't mention the ThreadPool. they even manage to "explain" without using the word "thread" (except for the silly sentence "Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe." which they have on most every page). :~
Luc Pattyn [My Articles] Nil Volentibus Arduum iSad
-
Well, it doesn't show it, what it does is proof or disproof depending on whatever the behavior is when you actually run that code. Will it hang waiting for exit? or will it ever report something? They don't mention the ThreadPool. they even manage to "explain" without using the word "thread" (except for the silly sentence "Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe." which they have on most every page). :~
Luc Pattyn [My Articles] Nil Volentibus Arduum iSad