This topic has been archived. It cannot be replied.
-
工作学习 / IT技术讨论 / 请教大家一个技术问题, UNIX系统下, 如何写一个C程序, 能够在异常中断后程序重启时自动恢复文件读写指针(即接着上次中断的断点接着读写).
-albxu(Yukon);
2001-4-11
(#44057@0)
-
What kind of abnormal trap? Power-off? Killed by a signal?
-marcow(UserMarco);
2001-4-11
(#44105@0)
-
You may think it's been killed or just core dumped.
-albxu(Yukon);
2001-4-12
(#44334@0)
-
Be killed and core dump is two storiesYou can write signal handler to save current position of file
pointer when your process catch kill signal;
I don't think you can deal with core dump easily. This is a
transaction issue, I think.
-marcow(UserMarco);
2001-4-12
{200}
(#44371@0)
-
I had the same thought as yours but just not sure if there is a final solution.
-albxu(Yukon);
2001-4-12
(#44424@0)
-
wrong, the SIGKILL signal can never be caught or ignored. The
best you can do is to call atexit(), but I doubt if it works for default
signal handler
-lumlumq(lumlum);
2001-4-12
(#44828@0)
-
You are right. It should be singal instead KILL singal.
-marcow(UserMarco);
2001-4-12
(#44865@0)
-
一个很stupid的solution：lock file？
-pasu(InTheSky);
2001-4-11
(#44128@0)
-
But how could you re-open the same file? It was a quiz in my previous interview two years ago by a Waterloo guy. I don't have the answer right now. Hope someone has the smart idea. People may be asked the same question in their interviews.
-albxu(Yukon);
2001-4-12
(#44330@0)
-
Which file did you mean? Sorry, I am not good at programming...just blind guess...hehe.
-pasu(InTheSky);
2001-4-12
(#44420@0)
-
any file that can be read and write.
-albxu(Yukon);
2001-4-12
(#44426@0)
-
?? I mean what's the "same file" you mentioned. You mean you cannot locate the file you once write to it or you cannot write to it any more?
-pasu(InTheSky);
2001-4-12
(#44467@0)
-
It's 接着上次中断的断点接着读写. The file is always accessible.
-albxu(Yukon);
2001-4-12
(#44521@0)
-
Then why could'nt you re-open the same file? I am really puzzled.
-pasu(InTheSky);
2001-4-12
(#44525@0)
-
Then how do you know where you stopped last time. This is the point. Remember you program stopped abnormally, your work in the file was half done.
-albxu(Yukon);
2001-4-12
(#44539@0)
-
a huge topic
-lumlumq(lumlum);
2001-4-12
{2457}
(#44824@0)
-
Thank you, Lumlum. This is the kind of anwser I've been waiting for. You're really good.
-albxu(Yukon);
2001-4-12
(#44831@0)
-
"lumlum" is very happy to hear that, xixi,,, ^_^
-lumlumq(lumlum);
2001-4-12
(#44854@0)
-
You two are using the same account. hehe. I get you!
-pasu(InTheSky);
2001-4-12
(#44898@0)
-
lumlum is really high hand. Admire you. But I don't think the access cannot be an atomic transaction.In my uderstanding, atomic transaction means get all done or get nothing done. The process can just restart at the last logged point. Then it's atomic. Do you think so?
-pasu(InTheSky);
2001-4-12
{169}
(#44846@0)
-
I guess you are talking about DBMSyour concept of atomic transaction is correct. But your atomic transaction is a solution to concurrency control, not to database recovery. The atomic transaction you referred to can guarantee that no two transactions
interleave each other, thus prevent "lost update" problem, but it doesn't help a failed system.
-lumlumq(lumlum);
2001-4-12
{318}
(#44945@0)
-
In my uderstanding, I should make the writing an atomic operation.
-pasu(InTheSky);
2001-4-12
{660}
(#44559@0)
-
Yes. It works. I didn't think of it at the first place. I went to think about the i-node structure to dig out what could help me.
-albxu(Yukon);
2001-4-12
(#44733@0)
-
哈哈，看来三脚猫有三脚猫的好处啊！懂得深的反而一头栽进去了，hoho。
-pasu(InTheSky);
2001-4-12
(#44753@0)
-
no, it won't completely work, it can only increase your chance to
recover data.What if you have written to the log file the current position, and the power is off. In this case the process hasn't really done any read or write operation yet, the outcome is that your log file has recorded the change that hadn't really ocurred.
-lumlumq(lumlum);
2001-4-12
{249}
(#44835@0)
-
yes. you are right. let's write the log after write the working file.
-pasu(InTheSky);
2001-4-12
(#44900@0)
-
Then what if the system crashes before you have time to write the log,
but after you have successfuly done read or write operation?
-lumlumq(lumlum);
2001-4-12
(#44911@0)
-
Just do it again according to the log. It's the way RDBMS works in nowadays.
-pasu(InTheSky);
2001-4-13
(#45320@0)
-
我觉得你还是没有把问题阐述清楚文件顺序读写本来就是可以接在原来的文件后面继续写的。一般来说系统先将内容在内存BUFFER，一定时间以后再写磁盘，或者在文件关闭的时候写，当然如果用 int fflush( FILE *stream ) 可以强制写磁盘，那么你的文件断点总是在最后处，下次打开直接接着写就是了。总之如果你能把情况说的更清楚一些，我们就可以对症下药了。:-)
-flying_snow(飞雪浮冰);
2001-4-12
{301}
(#44743@0)
-
This was not my question. I was asked this question before. It all depends on how you answer this question. Your anwser may get an excellent score. It's all up to the interviewer.
-albxu(Yukon);
2001-4-12
(#44751@0)
-
Yeah, the guy just wants to dish out how well you understand
the operating system.
-lumlumq(lumlum);
2001-4-12
(#44949@0)
-
不一定。比如数据库，一般都是先申请一片空间，然后再在其中写内容。这样的话，断点就不会在最后了。
-pasu(InTheSky);
2001-4-12
(#44757@0)