2006-08-22: Keith Bennett dixit: > On Mon, Aug 21, 2006, EV wrote: > Not got time to read it properly but I'm not sure that I like > it. It appears that you now build the properties list *before* > checking for duplicates and then delete it again at the end. I > preferred the previous method of only creating properties after > checking for duplicates.
The main load of lk_rio_update_props_from_tags() is that of computing the rid, which must be computed before checking for duplicates. The remaining properties need much less computing (they don¡t need to scan the full file). And it is not logical that a function devoted to update properties also searches for duplicates... > What was your reason for changing it? I don't remember right now, but I needed to change it in relation to accessing the virtual lkarmafs files from within lkarmafs required. > > 2006-08-21: EV dixit: > > The idea is not to set any default genre, artist, source or > > title *before* calling taglib. Instead, wait to see if > > taglib doesn't > > Why should this matter? Otherwise, the lkarmafs virtual name of the file keeps changing during the invocation of lk_rio_update_props_from_tags(), leading to segfaults within taglib. > I also think that the fdb locking fix is the wrong way to go. > The old version of riocp only grabs an i/o lock when there is > something to write. This is correct behaviour. The problem is > that the fdb file is uploaded regardless of whether anything > has changed. This can be fixed if we have a flag which gets set > when the properties change. I implemented this fix last night > and it seems to do the job, although I haven't done much > testing yet. It does not matter for riocp, as all the writting operations are made in a batch after grabbing the write lock lock. > On a related note, I think that the library should be a bit > smarter about i/o locking. There should be flags for read/write > io locks and the functions which require a lock to be held can > then check those flags before attempting the operation. Agreed. > I will need help to implement this as the ethernet protocol > does not seem to be particularly well documented with respect > to i/o locking. Moreover, you'll need a RK with a working Ethernet interface ;) Best, EV. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-karma-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-karma-devel
