View previous topic :: View next topic |
Author |
Message |
PlasmaJohn
Joined: 04 Mar 2005 Posts: 70 Location: The Garage
|
Posted: Tue Sep 15, 2009 15:46 Post subject: ExportSingleCharacter() |
|
|
As noted in this thread on the Higher Ground forums the ExportSingleCharacter() NWScript call returns immediately and performs the save in the background. We ran into this issue when testing my new Vaultster rewrite for Linux. We also noticed this happening on the Windows side if the bic was too large.
Anybody know if nwserver uses file locking on both Windows and Linux? If so, what style?
Thanks |
|
Back to top |
|
|
Zebranky
Joined: 04 Jun 2006 Posts: 415
|
Posted: Tue Sep 15, 2009 21:20 Post subject: |
|
|
... eww. And I was pretty convinced that it was synchronous, based on how often Win32 Vaultster worked.
Yeah, ExportSingleCharacter just sets an "export this character" flag, which is later handled by CServerExoAppInternal::ExportPlayer(), and more specifically CNWSPlayer::SaveServerCharacter(), and MORE specifically CNWSPlayer::BackupServerCharacter(), which includes the strings "rb" and "wb"... from there it's pretty straightforward.
Unfortunately, it appears the locking only happens while the file write is occurring. Perhaps the best approach would be a hook on the export function to call back to a script when CServerExoAppInternal::ExportPlayer() is done. I'll take a look, but I haven't done any script callback hooking, so there's some knowledge to be acquired first.
CServerExoAppInternal::ExportPlayer() is 456A40 on Win32, 80AFF10 on Linux. _________________ Win32 SVN builds: http://www.mercuric.net/nwn/nwnx/
<Fluffy-Kooshy> NWNx plugin is to this as nuclear warheads are to getting rid of fire ants.
<ThriWork> whenever I hear nwn extender, I think what does NWN need a penis extender for? |
|
Back to top |
|
|
elven
Joined: 28 Jul 2006 Posts: 259 Location: Germany
|
Posted: Tue Sep 15, 2009 22:22 Post subject: |
|
|
Not actually sure if this solves the problem in question, but what about using inotify (on Linux, Windows has something equivalent - I hope) to monitor things, and just copy the stuff that changes? Just let the kernel do the work for you. |
|
Back to top |
|
|
PlasmaJohn
Joined: 04 Mar 2005 Posts: 70 Location: The Garage
|
Posted: Tue Sep 15, 2009 22:45 Post subject: |
|
|
Zebranky wrote: | Unfortunately, it appears the locking only happens while the file write is occurring. |
That's fine if they're using an OS file lock, in that case I can just poll the lock status myself. If they are using one on Linux, hopefully it isn't flock() which is not compatible with NFS (according to one manpage)
elven wrote: | Not actually sure if this solves the problem in question, but what about using inotify (on Linux, Windows has something equivalent - I hope) to monitor things, and just copy the stuff that changes? Just let the kernel do the work for you. |
Thanks, I'll look into it. |
|
Back to top |
|
|
elven
Joined: 28 Jul 2006 Posts: 259 Location: Germany
|
Posted: Tue Sep 15, 2009 22:51 Post subject: |
|
|
FWIW, I don't think the Linux server uses locking at all. It just, sort of, well, overwrites the old file. |
|
Back to top |
|
|
PlasmaJohn
Joined: 04 Mar 2005 Posts: 70 Location: The Garage
|
Posted: Tue Sep 15, 2009 23:01 Post subject: |
|
|
Re: inotify
Nice! IN_CLOSE_WRITE will work just dandy for me.
Horridly non-portable unfortunately. Hm... pnotify is an attempt to create a portable version on top of inotify , kqueue and the NTFS Change Journal. A quick glance through the documentation doesn't show anything as nice as IN_CLOSE_WRITE. |
|
Back to top |
|
|
|