LanManFS bounty

May I suggest a clean rewrite. LanManFS is fine for copying files but once you play around with manipulating archives or playing audio/videos you can easily end with issues like “LanMan in use”. See here

Bidirectional mapping from Unicode to the RISC OS alphabet

What is the RISCOS alphabet ?

Individual file sizes will be clamped at 4GB in line with the RISC OS API

May I suggest it is time to introduce a bounty for a new API to handle larger file sizes. I don’t care about thinks like journaling or metadata but I’d like to be able to try the few 20GB+ MPEG2 TS videos on my development version of KinoAmp ;-)

What is the RISCOS alphabet ?

Whatever *Alphabet is set to – usually Latin1.

a new API to handle larger file sizes.

And a 64 bit integer type in BASIC? ;-)

May I suggest it is time to introduce a bounty for a new API to handle larger file sizes.

This was planned for Filing system improvements (step 3) and Filing system improvements (step 4), but we have yet to finish Filing system improvements

I think this is the step outline followed:
https://www.riscosopen.org/forum/forums/8/topics/612?page=2#posts-8599

you can easily end with issues like “LanMan in use”

I don’t think it can be solved – or at least I couldn’t think of a way to do it. The problem is reentrancy. If the only clients to the module were applications then there wouldn’t be a problem as transactions would be completed before the next app got its turn.

The problem is when the module is called from a callback while the module is in use eg a large file is being transferred and a music module is streaming data over the same share – all transactions on a share are over a single socket. There’s no way to make the music streaming or file transfer wait – if riscos was preemptive you could use a mutex lock but unfortunately it isn’t. Ideally callbacks would be halted while the module does its stuff but they have to be explicitly enabled for sockets to work.

if riscos was preemptive you could use a mutex lock but unfortunately it isn’t. Ideally callbacks would be halted while the module does its stuff but they have to be explicitly enabled for sockets to work.

I think we’ve been in this scenario a few times before. My mind says if the hardware had multiple cores and we set one of those cores doing a PM thread for specific I/O tasks where the most obvious answer to a problem is PM then perhaps it might be workable.
The typical x86 style PC usually has a NIC with its own small CPU¹ dedicated to taking load of the main OS CPU, this is just a variant of that concept.
How far has Jeffrey got with the multicore work he was doing?

Edit: No doubt someone will say “well what do I do if I only have a single core?” and the answer is – “exactly what you do now”
Some software features are going to need newer hardware, that’s life. Add a feature if the hardware supports it, don’t do anything to older stuff that breaks what works, after a fashion.

¹ Said small CPU being an ARM core would not surprise me in the least.

If the module can detect the reentrancy, can it return reads or writes saying that no bytes have been transferred? Well written code should check for this and re-try.

I can see problems with code that doesn’t check for unexpected transfer lengths, and I can see an infinite loop happening if there’s no wimp poll in the retry loop.

The problem is when the module is called from a callback while the module is in use eg a large file is being transferred and a music module is streaming data over the same share – all transactions on a share are over a single socket. There’s no way to make the music streaming or file transfer wait – if riscos was preemptive you could use a mutex lock but unfortunately it isn’t. Ideally callbacks would be halted while the module does its stuff but they have to be explicitly enabled for sockets to work.

The DiskSample module tries to work around the callback issue as best as it can, using a few tricks. LanMan98FS returns error 0×100A0 when it notices a re-entrency issue, for some FS (like ShareFS IIRC) OS_FSControl, 47 works in the foreground but return an error if there a re-entrency issue is detected so it is a way to check that I would have a issue when attempting to read data from a file during a callback but a generic solution would be more than welcome.

That said callback are not the only cause of the “LanManFS in use” issue. I had that problem several times when playing videos and there it is KinoAmp itself which reads the data.

How far has Jeffrey got with the multicore work he was doing?

I did the “hard bit” of getting things to a state where code can be run on other cores, for all multi-core platforms currently available from ROOL, except for Titanium (some HAL changes are needed).

However we still need to do the “boring bit” of writing a proper threading system/API for the SMP module to implement, and making some useful bits of the OS thread-safe (e.g. OS_Heap) so that threaded code isn’t completely impotent.

However we still need to do the “boring bit” of writing a proper threading system/API for the SMP module to implement, and making some useful bits of the OS thread-safe (e.g. OS_Heap) so that threaded code isn’t completely impotent.

I thought the boring bit was doing the documentation.
Of course at this point in my imagination Clive leaps forward and says, with a flourish, “fear not, I have done ARM documentation and this will be but a moments work”

OK, that’s me struck off the Semmens Christmas card list…

I thought the boring bit was doing the documentation.

I think it depends upon the mindset. Generally programmers find it boring to write documentation because they already know the program inside and out (which is why so many programs have rubbish documentation, if they have any at all).

People who write documentation for a living, on the other hand, might find it an interesting exercise. How does one explain “thing” in a clear and unambiguous way? It can be harder than it seems, because you need to cover all sorts of user questions in advance (yes, you press Return to make it work) but you can’t be patronising.

Probably the actual boring bit is debugging – whether the programmer checking the software, or the documentation writer checking the text. Familiarity can sometimes be a bad thing, you miss something right in front of you because you’ve read it so much your mind is reading it on autopilot and you literally don’t notice the missing character…

Probably the actual boring bit is debugging

Maybe that’s why I do support, I like solving puzzles like a bit of software or hardware misbehaving.

Today: Digging and discovering that a firewall isn’t logging certain events because the 3rd party that set it up enabled logging on a particular rule but set neither a “at beginning of connection” nor a “at end of connection” trigger – outstanding.

Documenting things, bleh.