Re: Re[2]: MailBox development impuls

> * Wiggins d Anconia ([email protected]) [040727 15:43]:
> > If the code forks you may be experiencing the same thing I mentioned
> > back in 11/2003.
> > 
> > http://marc.theaimsgroup.com/?l=perl-mailbox&m=106796841320810&w=2
> 
> I am always trying to answer to all problems... if I do not answer, it
> means the message was lost... with the amount of spam and other stuff I
> get in my mailbox, it sometimes happens that I accidentally remove
> something I should read, so please push them again after a few days...
> 

Sorry didn't mean to imply that a response was expected, we fixed it in
our version (not nearly as well as yours I am sure) and moved on,
figuring the fork safety wasn't a big concern.

> Your discription of the problem is quite clear: in some situations,
> MailBox can create non-unique message-IDs.  On the moment, when MailBox
> is started, it takes 'time'. and then increments this each time a
> new ID is needed.  But when you play with forks within MailBox, that
> is not sufficient: the unique value will not get incremented over all
> threads and may cause collisions.
> 
> You suggest to Time::HiRes as message id.  My problem with that, is
> that it requires a system-call for each id created.  In the current
> solution, it is only one "time" per program.  However, adding a
> random value will probably call the system as well... and is even
> less safe.
> 

Yeh the random value sounds like a nightmare.  No problem, avoiding a
system call is always a good thing where possible.

> Time::HiRes... needs a fallback for systems where it is not
> installed/available....
> 

Yeh I wasn't sure what M::B's minimum core version was, and whether it
was provided in that. Of course some systems wouldn't have it all.

> Ok,... it was not that easy, but I have implemented a new numbering
> scheme for the next release:
> 
>   Mail::Message::Head::Complete->messageIdPrefix(...OPTIONS...)
> 
> now can have a
>   PREFIX   string  (defaults to mailbox-$$)
>   HOSTNAME string  (defaults to Sys::Hostname || localhost)
> inbetween, Time::Hires::gettimeofdat is used when available, otherwise
> the current unique_id++
> 
> You may also specify your own
>   CODE-ref
> 
> I have tested all three... will be in the next release.

Excellent, I will try to check it out and see what the implementation
looks like.  I would love to put it in production but I am not sure when
I will be allowed to upgrade the module suite, not to mention we are in
a code freeze right now anyways.  We are still stuck on 2.041 :-(.  Also
haven't heard back from the OP, while I assume this fix will help him as
well, don't really know.

Thanks as always for M::B and your other modules,

http://danconia.org