Re^2: Can I expect to have ithreads available?

This is as part of the client for a file-syncing application, somewhat like Dropbox. (It's a university project.) It basically has three broad responsibilities—monitoring the filesystem, watching the server for remote changes, and uploading and downloading files. I'd like to split these into three communicating threads or processes.

Using threads would allow me to pass full objects around through something like Thread::Queue, instead of having to serialize the data somehow onto a socket or pipe, so if that's a viable solution it strikes me as likely being better.

=cut
--Brent Royal-Gordon

Comment on Re^2: Can I expect to have ithreads available?

Replies are listed 'Best First'.
Re^3: Can I expect to have ithreads available? by rowdog (Curate) on Nov 02, 2009 at 06:36 UTC
My reading of the tea leaves says you're planning on rolling this app out onto a bunch of oddball departmental servers which are probably not under your direct control. If your school is anything like the university I worked at, that means some of those machines are crust old boxen that should just be shot and put out of their misery, but geology has to have that exact version of perl 4 to support their favorite app. Sigh. So, what happens if the threaded code doesn't work on every single machine? Is the project a failure or will your PHBs be happy with 95% coverage? Can you go install a private version of perl on the machine in question? Is that ancient server lurking in some obscure corner of the campus going to come back to haunt you? That said, sure, reasonably up to date versions of perl will typically be compiled with ithreads on the major platforms. Really, it's up to you to make the call, but those are the points I would consider.	[reply]
Re^4: Can I expect to have ithreads available? by BrentDax (Hermit) on Nov 02, 2009 at 10:52 UTC
Actually, the Perl component is a per-user daemon on the client. The server (which I'm not directly responsible for) is PHP over Apache, with the idea that you could just throw it up on commodity shared hosting if you wanted to. This is a final-year programming project we're doing for undergraduate computer science credit. The basic story is that our supervisor's office is across the hall from the university's IT guys, and one of the IT guys wants an "open-source Dropbox I could run from my own servers". He's giving us very free reign with the project; we're largely determining the system requirements ourselves. But I'm trying to define those requirements in such a way that this will be broadly usable. I suppose if necessary we can actually ship/build a suitable perl with the client; that just seems a bit extreme... =cut --Brent Royal-Gordon	[reply]