Boost logo

Boost :

Subject: Re: [boost] [interprocess] file_mutex class proposal
From: mateusz janek (stryku2393_at_[hidden])
Date: 2018-03-14 18:48:10


I don't think so. AFAIK you can not lock a file with file_lock and then
write/read to it. file_lock's purpose is not to synchronize access to
passed file. It's more like mutex, but it uses file on disc to synchronize.

Mateusz

2018-03-13 12:02 GMT-07:00 Richard Hodges via Boost <boost_at_[hidden]>:

> Isn't the signature of boost::interprocess::file_lock already compatible
> with std::unique_lock<> etc? Or do i misunderstand something?
>
> R
>
>
> On 13 March 2018 at 18:07, mateusz janek via Boost <boost_at_[hidden]>
> wrote:
>
> > Hey, any thoughts on that?
> >
> > Thanks,
> > Mateusz
> >
> > 2018-03-04 3:42 GMT-08:00 mateusz janek <stryku2393_at_[hidden]>:
> >
> > > Hello boost::interprocess community,
> > >
> > > During my pet projects development I found that a file access
> > > synchronization is a common problem so, I wrote a class that wraps it
> and
> > > thought that it can be useful for wider community. I would like to ask
> > you
> > > what do you think about such functionality in boost::interprocess? I'm
> > > aware that class from the repo is not ready to release. Just wanted to
> > show
> > > about what functionality I'm talking about.
> > >
> > > Here you can find the repo: https://github.com/stryku/file_mutex
> > > You can find there the proposed class and a simple usage example.
> > >
> > > If you will find it interesting I will prepare more formal merge
> > proposal,
> > > update docs, maybe more examples etc.
> > >
> > > Looking forward to hearing from you what do you think about it.
> > >
> > > Thank you,
> > > Mateusz Janek
> > >
> > >
> >
> > _______________________________________________
> > Unsubscribe & other changes: http://lists.boost.org/
> > mailman/listinfo.cgi/boost
> >
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk