One annoying downside to dealing with an interpreter, or other generally 'low-level' infrastructure is the grotty details that you must deal with. IO details, interrupt level code, signals, platform calling conventions.. We don't have the luxury of ignoring them the way that a utility or application might. Today's fun task is to design a generic thread-safe and interrup-safe queue. That is, a queue that you can safely insert into from normal code or a signal handler/interrupt handler/AST, while user code is potentially removing elements.
Some platforms, like VMS, make it easy. Guaranteed-safe queues are provided by the platform and we don't have to do any work at all. They're even fancier than we need for parrot, since our needs are specific. We can guarantee that only user mode code is draining the queue, only user mode and one interrupt mode piece of code can possibly be simultaneously inserting into the queue, and user mode code won't be simultaneously inserting and removing elements from the queue, so we don't have to worry about conflicting AST routines trying to jam into the queue at once, or the different AST, user, and thread routines are inserting and draining simultaneously.
Still.. try this one in generic, ANSI C. You find yourself playing all sorts of evil games with volatile, double-check modifications, and mutexes. Mutexes almost make it easy, as they let you force single-threading in user code, but they aren't the complete solution since signal/interrupt/AST code can't do mutexes. The last thing you want is your interrupt handler to block on a mutex, after all. That's... bad.
Anyway, annoying code, but code that must be done. When I've got it, I'll post or link to it, since it's useful. After I throw it into the public domain, because I hate license issues.
Posted by Dan at March 14, 2003 03:30 PM | TrackBack (0)