#152 ✓invalid
bahuvrihi

Tap-Server Threading

Reported by bahuvrihi | February 12th, 2009 @ 08:29 AM

The server ideally will accept requests, return quickly, and then do work. To do so requires some sort of threading... but of course it's hard to guarantee all tasks may be threaded. I propose a three-mode model:

  • blocking - Each app runs on main thread preventing return of current request and handling of new requests
  • threaded - Only one app may execute on one execution thread at a time. All other apps block until the current app is done. This could be implemented with a queue so that a request may return and the app will wait it's turn to produce results.
  • multi-threaded - Each app runs on it's own thread.

blocking

No attention to threading required.

threaded

Threading requires each app is self-contained: all objects used by the app are it's own (queue, tasks, dependencies, etc). This is almost the case, although there are some outlying (bugs)[http://bahuvrihi.lighthouseapp.c...].

Threading is less save than blocking but should not be dangerous provided no apps run off-queue. Effectively there are only two threads:

  • The server thread which utilizes env, interacts with the user, but does not work with apps or tasks (this could be an issue with globals).
  • The application thread which runs apps, but does not interact with the user or utilize env.

multithreaded

Multithreading also requires each app is self-contained.

Comments and changes to this ticket

  • bahuvrihi

    bahuvrihi February 12th, 2009 @ 08:32 AM

    One big issue is that schema modify globals. In the single-app model, one app might be running a schema with globals in one configuration, then be enqueued with a new schema that modifies globals.

    There should be a schema queue

    One schema executes, then another. Ensure a single app does not handle more than one schema at a time.

  • bahuvrihi

    bahuvrihi February 16th, 2009 @ 10:29 AM

    Tasks should have a lazy_attr that indicates whether or not they are thread-safe (true/false/nil). This can serve as a filter for even allowing multithreading in the server.

  • bahuvrihi

    bahuvrihi May 25th, 2009 @ 12:16 PM

    • Assigned user set to “bahuvrihi”
    • State changed from “new” to “invalid”

    This was too complicated to manage. Now servers have one thread to run the single server app and the main thread handles requests.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

A framework for making configurable, file-based tasks and workflows.

People watching this ticket

Tags

Pages