Jump to content

  • Log In with Google      Sign In   
  • Create Account

nife87

Member Since 03 Aug 2007
Offline Last Active May 10 2013 05:11 AM

Topics I've Started

Hiding multiple schemes within URI

13 February 2013 - 02:54 PM

I am currently writing a URI parser whilst reading the official documentation and noticed that it should be legal to conceal another/multiple schemes within the URI syntax. I would like to be able to specify multiple schemes within a valid URI, like so:

vfs:zip///home/user/test.zip

vfs:zip:file///home/user/test.zip#data/text.log

vfs:zip:file//user:encrypted-password@localhost:127/home/user/test.zip#data/text.log

 

According to the Generic Syntax (RFC 3986), specifically sections 3 - 3.3 (not all text is listed here):

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
 

This means that any characters between the first ':' and the first '/' (specifying either authority or path) should be skipped by parsers and still validate the URI, enabling me to provide zero or more schemes (zip, file, http, etc.) after the primary scheme (vfs, in this case), as far as I can tell.

 

Any thoughts as to whether or not this is correctly understood?

 

Otherwise, I think I have to provide the additional schemes via the path part or as a query or fragment, although I would prefer to provide them up-front, like the above, in order to preserve the rest of URI from preliminary preprocessing (other than normalization and percent-decoding).


Thread-safe iteration/traversal

31 July 2011 - 12:11 PM

This is for C++, but the question also applies to programming in general. I am just beginning to learn concurrent programming for real, and some serious issues are starting to pop up.

Normally - single-threaded, that is - when you have a class which manages objects of some sort in a structure, be that an STL container of just some custom tree with a parent pointer and children pointers for each node, and you want other classes to be able to iterate/list its contents, you have several options/patterns, but I cannot seem to make iteration thread-safe from outside the managing class.
Internally, from inside the managing class, you can lock its internal mutex(es) and iterate, thereby ensuring thread-safety while iterating. This is how I am doing it now. Any comments on this?
For instance, Ogre3D has STL iterator wrappers which are given the start and end iterator (normally begin() and end()) of the container and just checks the validity before advancement.

But with multiple threads possibly altering the managing class, you cannot ensure thread-safety while iterating outside the class, since STL iterators are not thread-safe by themselves. How it this solved?

I am also pretty sure that it is not only the iterator pattern which suffers from thread-insafety when used "normally".

To mention some cases where I need to come up with thread-safe solutions, first I have a class managing the classic STL container with much data that needs to be listed/iterated, and then I have a custom tree structure which needs to be traversed, both listed below.

I have a memory tracker which can return a list of memory leaks. Right now I just lock the internal mutex via a scoped lock and return a copy of the container containing the memory leaks (actually, it contains all tracked allocations, which is then considered memory leaks if they were not present at first). This is fine, because I only do it once, just before exiting the program. Doing it frequently at run-time, however, I would prefer not to copy the contents every time, as it may contain quite a lot of data. This can be solved by the returning iterators, such as the ones used within Ogre3D, for single-threaded programs - what about multi-threaded programs?

I also have a virtual file system containing a node for each directory. Each node consists of a parent pointer (weak pointer), a container with subdirectories (shared pointers), a container with links (weak pointers to other nodes) and, finally, a container with files (shared pointers). Each file then consists of multiple file data (shared pointers), first prioritized by custom priority and secondly by last modified timestamps in order to control/merge overlapping file systems (for instance, the real game directory may contain directories/files which also exist in the archives - both are then merged into a single virtual file system).
How would I go about thread-safely traversing this tree?

Thanks in advance.

Templated operator! overloading

15 October 2010 - 07:47 PM

I'm having a somewhat hard time figuring out why GCC won't accept this pointer check (operator!):

template<typename T> class P
{
public:
typedef boost::weak_ptr<T> Weak;
};

template<typename T> bool operator!(const typename P<T>::Weak &p)
{
return (!p.expired() && p.lock().get() != 0);
}

...

P<int>::Weak p;

if (!p) // error here!
dosomething();

GCC complains about "no match for 'operator!' in '!p'"?

Multi-threaded compilation

11 April 2008 - 11:09 PM

Hi I will soon assemble a quad-core desktop, so I am, naturally, interested in using all 4 cores for compilation. I am sure that some of you must have had this dilemma when switching from single-core to dual/quad-core, so I am just looking for advice on how to speed up compilation times with multiple cores. Normally, I use Code::Blocks with GCC on both Ubuntu/SUSE and Windows (without makefiles), so, naturally, I would be very pleased if I could somehow maintain this form of development without having to maintain my own makefiles (which AFAIK can accomplish this by the use of the "make -jN" switch). By the way, I am also aware of the fact that MSC can make use of multiple cores, but I try to use cross-platform tools only, so this is not an option. In advance, thanks for your time.

PARTNERS