On 14.03.24 21:21, Joan Moreau wrote:
I am trying to avoid closing/ reopening a file pointer to the exact same file
between each call to the plugin
That's still a "what" and not a "why". Long before you'll run into any
serious resource problem, that file will be firmly seated in the disk
From: Joan Moreau
> I am trying to avoid closing/ reopening a file pointer to the exact same file
> between each call to the plugin
Can't you do an end-run around all this by having a persistent standalone
process that holds all your persistent data, and the plugin collects session
data and
Thanks Eduardo
I am trying to avoid closing/ reopening a file pointer to the exact same file
between each call to the plugin
On 14 March 2024 20:08:37 Eduardo M KALINOWSKI via dovecot
wrote:
On 14/03/2024 02:49, Joan Moreau via dovecot wrote:
No, you don´t understand
On 14/03/2024 02:49, Joan Moreau via dovecot wrote:
No, you don´t understand
There is a core process (/usr/bin/dovecot) running all the time. So I want to
allocate a memory block, the core process keep it and it is retrievable by the
pluging when laded again
At exit of /usr/bin/dovecot, it just
I do understand, and the problem is that your question is similar to asking how
to get a memory pointer from systemd for your program.
The short answer is, not doable.
The bit longer answer is that /usr/sbin/dovecot is a fancy service supervisor,
it's job is to launch and manage processes, it
No, you don´t understand
There is a core process (/usr/bin/dovecot) running all the time. So I want to
allocate a memory block, the core process keep it and it is retrievable by the
pluging when laded again
At exit of /usr/bin/dovecot, it just does a "delete()" of the said allocation
On
Hi!
Sorry but that's just not possible, ther is no "core" where to create such
object. There is no "dovecot" where to store things.
When user logs in, dovecot executes /usr/libexec/dovecot/imap and transfers the
connection fd there. then plugins and stuff are loaded, and the user does what
he
No, I am not referring to that
I want to create an object at first call in memory
that object would be retrievable at second and furthers calls of the plugin, as
long as dovecot is running
On 2024-03-13 16:29, Aki Tuomi via dovecot wrote:
Not really no. You should use e.g. dict inteface
Not really no. You should use e.g. dict inteface for storing this kind of
stateful data. When deinit is called the calling core process will likely die
too.
Aki
> On 13/03/2024 10:19 EET Joan Moreau wrote:
>
>
> Keep a pointer in memory retrievable each time a plugin is called
>
> So the
Keep a pointer in memory retrievable each time a plugin is called
So the plugin keep the memory, not has to restart everything at each call
On 12 March 2024 08:53:38 Aki Tuomi via dovecot wrote:
On 11/03/2024 10:42 EET Joan Moreau wrote:
Hi
Is it possible,
> On 11/03/2024 10:42 EET Joan Moreau wrote:
>
>
> Hi
> Is it possible, from a plugin perspective, to create and recover a pointer in
> the core process (i.e. memory not lost between 2 calls to the plugin, even
> after the "deinit" of the plugin" ) ?
>
> Thanks
Hi Joan!
May I ask what
Hi
Is it possible, from a plugin perspective, to create and recover a pointer in
the core process (i.e. memory not lost between 2 calls to the plugin, even
after the "deinit" of the plugin" ) ?
Thanks
___
dovecot mailing list -- dovecot@dovecot.org
To
> On 11/03/2024 12:53 EET Aki Tuomi wrote:
>
>
> > On 11/03/2024 10:42 EET Joan Moreau wrote:
> >
> >
> > Hi
> > Is it possible, from a plugin perspective, to create and recover a pointer
> > in the core process (i.e. memory not lost between 2 calls to the plugin,
> > even after the
13 matches
Mail list logo
