TINN Version 0.7 Available

Although TINN is under constant development, there’s nothing like declaring a new “release”. It’s been 3 months since the 0.6 release. So, now there is a 0.7 release. You can read about the TINN v0.7 Release and install it if you would like.

There were 84 commits since the previous release, so I can’t even remember all the changes that were involved. The major addition from my most recent work has to do with the new scheduler as described on this blog. That’s the extensible, plug-in driven scheduler. Pretty nifty for my work at least.

There are quite a few additions, such as a revamped stream object, io completion port supported file interface, a logfile thing, and quite a few more interfaces from the OS.

Other items I have been working on include support for various COM interfaces such as DXGI, DXVA, MMDevice and some others. There are all in the “experimental” folder if you look at the enlistment. They are not quite ready for prime time, so they’re not actually in the v0.7 release.

What can you do with TINN? In short, you can create all sorts of Windows based applications. Everything from scalable web services to interactive multi-tasking UI (including OpenGL based).

TINN is a command line tool (tinn.exe). As such, the easiest thing to do is bring up a command line shell and run various scripts through tinn.

c:\> tinn.exe hello.lua

The TINN repository contains numerous test cases that utilize the various modules of TINN.

That’s it for now.  Next release will be about cleanup and stabilization primarily.

4 Comments on “TINN Version 0.7 Available”

  1. nemesisqp says:

    I just look at the project, it pretty big and there some good solution, is there any way to avoid the hot poll at application.step ?, call GetQueuedCompletionStatus every 20ms seem hot but I can’t think of anyway to pass INFINITE while not stuck at GetQueuedCompletionStatus T_T

  2. Between the application object and the scheduler, tinn tries to provide the flexibility to support multiple application patterns. If you want full io event driven, go for INFINITE quanta. If you’re doing a game, probably quanto of 0, as you want the various coroutines of the game to get maximum time.

    If you want some threads, you could add computicles to the mix. But yes, that’s a good design decision point for your particular app.

    • nemesisqp says:

      I will try to reorder the step function a bit then go with GetNearestDueTime style and use that for GetQueuedCompletionStatus timeout, if none task waiting then timeout is INFINITE, this way I can use the wait_for_time stuff

      May be this is good enough for a net application

      • Things might be OK as they are for a typical net based application. I guess it depends on whether you’re trying to preserve cpu cycles or not. If you go with INFINITE, you’ll be stuck there, with nothing but an IO event to wake you up, assuming there was an IO request somewhere before that. I assume that’s what you want.

        Also, GetQuedCompletionStatus only retrieves one IO completion per iteration of the loop. That could be changed to retrieve multiple completions at the same time, and make the IO processing a bit more efficient than it is now.

        I would be interested to see how it goes for you. Ideally you’d be able to achieve the characteristics you desire without having to modify the core project, so I’d like to change it if I can to make that a reality.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s